
|
[haiku-appserver]
||
[Date Prev]
[10-2004 Date Index]
[Date Next]
||
[Thread Prev]
[10-2004 Thread Index]
[Thread Next]
[haiku-appserver] Re: drawing thread
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 21 Oct 2004 09:31:44 +0200 CEST
Hi,
First I want to say I'm sorry my responses lack a few days as well in
general, but this can't be helped (until I completely quit my day-time
job that is :)
--
Adi and Gabe, thanks for the explanation, it clears it up I think. So
the actual interface to the real graphicsdriver (accelerant) is that
subclass of DD, accelerant driver. If the engine is to be used, it will
be done from there. (calling the accelerants acc and management hooks).
---
BTW: Adi,
Again, I want to make one remark regarding something you react on from
DW (I think it was):
Just ignore it if you want: officially it's off-topic I guess..
> What about when two different threads need to write to overlapping
> areas of the screen? An excellent example would be when a developer
> goofs and overlaps two sibling BViews.
I don't really grasp all the details, but I want to mention
BDirectWindow anyway. It's up to you guys to see if this is related or
not, but from my perspective, I think I can see an app drawing directly
onscreen, but _outside_ it's assigned area because the app programmer
'goofed up'. Simple example, that game-demo released using voxels to
display a 3D world. It's making mistakes here bigtime. (not adhering to
clipping if another window is partly on-top of it's output window), and
making plain window location calculation mistakes sometimes).
It's very possible that the app_server is drawing in the same locations
at the same time a DirectWindow app is (app goofing up). Off course, if
this is in the graphicscard RAM, there won't be page faults (don't even
know if this is the right name for the error) or other crashing errors
anyway, just a big mess onscreen. I don't even know if you _can_ detect
this kind of fault (by hardware or software). I mean, if someone has an
overlay window for instance, they can also easily write outside it's
boundaries without getting punished by the system. This results in
cursorbitmap distortions or desktop distortions depending on the actual
layout of things in RAM. The one place where the app would get halted
is, if a bitmap lies on the boundaries of the cardRAMs area. (try
VideoPro on MAtrox G400-550 with 32Mb for instance).
Thanks for reading :)
Bye..
Rudolf.
|

|