Invalidation problems in 32bit mode wrt BDirectWindow

[johndrinkwater]

during bootup, select any 32bit screen mode

Start Chart, select DirectWindow, and start the animation.

Drag the window around, you'll find old frames accumulate on the surface, and rogue pixels will collect on the parent window.

Appears on 640x480x32 + 1024x768x32 + 1280x1024x32

Doesn't appear on same modes in 8 & 16 bit depths

[jackburton]

Chart assumes that the black background will be invalidated by the app server. For some reason, this doesn't seem to happen, or it happens too early, so the problem shows up. If the mode isn't 32 bit, the double buffering seems to hide the problem.

[stippi]

What do you mean "during bootup". Do you mean this bug appears in a VESA mode? I will check up on it later.

[johndrinkwater]

I presume it's VESA mode. i'm running in VMware, and cant change resolution with the Screen prefs, so I have to pick res at Haiku's bootloader screen.

[stippi]

Chart does certainly not assume the background is invalidated. If you look at the Chart code, there is a work arround for some BeOS app_server version for when it *does* clear the screen, which it is not supposed to. :-) However, the bug was that the direct window as allowed to start drawing again when the window contents had not been blitted to the new location yet.Please reopen bug if some different problems remain (I'm thinking VESA mode and this "frames" thing John mentioned, maybe it was unrelated).

[kutspam@…]

Dunno if this isn't OT but I have an Ati mobility m6 on an hp nc4010 (and I have to use the bebits radeon driver from Tomas Kurschel to see anything) I see the mouse cursor image being 'eaten away' by the dots in Chart, a cursor movement will reset the cursor image. Direct window, 800x600 (can't set the screen prefs although it uses the radeon driver (not radeon.driver!))

[stippi]

The dots eating away the cursor is perfectly normal behaviour and is expected with a software cursor. The idea behind BDirectWindow is that the application can bypass the app_server for drawing. When the app_server is used for drawing, it knows when to hide the software cursor and when to show it again, so that it doesn't draw over it. This is simply not possible with BDirectWindow. On R5, you cannot use a BDirectWindow when a hardware cursor is not supported. Haiku currently allows this, but the sideeffect is what you see. Still, perfectly normal and expected. :-)