[Top][All Lists]

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

Re: Display issues (Was: Next GNUstep release)

From: Riccardo Mottola
Subject: Re: Display issues (Was: Next GNUstep release)
Date: Fri, 13 Mar 2020 00:13:15 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1

Hi Sergii,

Sergii Stoian wrote:
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 
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.

I performed some tests by hacking xorg.conf ... I was a bit rusty at that, but a refresh does good. We are forced at home for cornavirus anyway.

I can enable/disable HW acceleration in the driver and force 16 bit or 24 bit.
This gives us 4 combinations!

1) Accel + 16 bit : GNUstep Broken as per original screenshot
2) NoAccel + 16bit : Everything Works fine!
3) Accel + 24bit: GNUstep slightly broken, like 16 bit but there is clearly a repaint where (mouse cursor ruins display, there is clearly a driver bug in this mode)
4) NoAccel + 24bit: works

so, clearly HW acceleration makes some difference.
I checked other apps, I did run not only WindowMaker, xterm, gvim, but also more difficult apps like emacs and firefox and they do look fine without the issues we have in both 16bit and 24 bit acceleration.

Interesting is GNUstep in 24 bit accelerated mode: it looks broken similar to 16bit, but in 16 bit a broken window is just broken and always look the same from the beginning (refresh, minimize, etc) and depends only on the size, in 24 bit it is different! in 24 bit accel, the window comes up and looks broken like in 16bit then immediately draws and looks "decent" (small glitches). However a move or a iconize/reopen will make it broken, like in 16bit mode.

My guess is that we do some double-buffering or shadow buffering somewhere and the two buffers are not "aligned"

What is common here to both cairo&xlib? I don't know if I mentioned, but when I tested 16bit-accel, I tested both backends! so it is not "cairo specifc". I did not test art because I don't have libart nor art fonts in this machine, but if you wish, I could try.


reply via email to

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