Re: Display issues (Was: Next GNUstep release)

[Riccardo Mottola]

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

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.

Riccardo