[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.