gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display issues (Was: Next GNUstep release)


From: Sergii Stoian
Subject: Re: Display issues (Was: Next GNUstep release)
Date: Sat, 29 Feb 2020 03:41:08 +0200

> On Feb 28, 2020, at 13:17, Fred Kiefer <address@hidden> wrote:
> 
> 
> 
>> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola <address@hidden>:
>> Sergii Stoian wrote:
>>> 
>>>> On Feb 27, 2020, at 23:09, Riccardo Mottola <address@hidden> wrote:
>>>> 
>>>> before a release, I would like these issues to find a solution.
>>>> 
>>>> - understand why we don't work properly on my ThinkPad T23 neither with 
>>>> the Cairo nor with the xlib backend with similar issues
>>> Could you please be more specific and describe these issues?
>> 
>> I have an issue I am working on with Fred, I can forward you some mail 
>> because they contain screenshot and I did not spam the mailing list.
>> 
>> Essentially I discovered that many windows contain "garbage" and what we 
>> discovered so far
>> - certain windows width cause garbage do be displayed, resizing the window 
>> may cause it do display correctly
>> - this garbage is compatible with an wrong offset increasing for each row 
>> (you see diagonal lines if  you have a white window with a border)
>> - the issue happens both with cairo and xlib (recent discovery of two days 
>> ago, before we were concentrating on a cairo issue)
>> 
>> it looks like an issue that somwehre a padding/alignment is lost: e.g. 
>> width*bytesPerPixel != bytesPerRow, but where?
>> 
>> I have not seen this issue elsewhere. The T23 is itself a pretty standard 
>> setup: Devuan ascii, GCC runtime, i386. Only the videocard is a little bit 
>> vintage/odd (S3) but it works with any other program except GNUstep :-P
> 
> You forgot to mention one important detail. This problem only shows up with 
> 16 bit depth. Most likely this happens as some data structure that holds the 
> intermediate pixel information rounds the line length to a multiple of 8, 16, 
> 32 or even 64 and we use one value below that, so we get an offset for each 
> line which leads to the displayed garbage. The problem is that I am not able 
> to reproduce the issue and don’t know which intermediate structure needs 
> adjustment.

It looks strange. Some regions which are roughly filled with XFillRectangle 
should look plain. But they don’t (Riccardo sent me a screenshots). We need to 
be sure the video driver works correctly. The next step is to understand what 
code in GNUstep drives that weird behaviour.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]