Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#111 closed bug (fixed)

Invalidation problems in 32bit mode wrt BDirectWindow

Reported by: johndrinkwater Owned by: stippi
Priority: high Milestone: R1
Component: - General Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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

Change History (10)

comment:1 Changed 13 years ago by axeld

Owner: changed from axeld to stippi

comment:2 Changed 13 years ago by 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.

comment:3 Changed 13 years ago by stippi

Status: newassigned

comment:4 Changed 13 years ago by stippi

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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).

comment:7 Changed 13 years ago by stippi

Status: assignedclosed

comment:8 Changed 13 years ago by stippi

Resolution: fixed

comment:9 Changed 13 years ago by 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!))

comment:10 Changed 13 years ago by 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. :-)

Note: See TracTickets for help on using tickets.