[haiku-appserver] Re: drawing thread

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 21 Oct 2004 12:21:16 +0300

Rudolf wrote:
> 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 :)

        :-))
        If you excuse yourself, what to say about me...? :-) Your emails are 
big and full of technical info and replying to them requires more 
time(&thinking) than usual ones. So here it is:
        Sorry for replying so late. [not the case now :-)) ]

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

        Exactly.

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

        Yup, we know about that. And that's how it's gonna stay. We can only 
give that window the region into which it can draw, nothing more. If it 
draws outside that region it means the app needs debugging/corrections. :-))

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

        Nope. app_server, at lest, can't.
        BTW, Yahoo Messenger 6 does that on Windows and I hate it, because when 
I'm playing OpenTTD (Open Transport Tycoon Deluxe) :-P in fullscreen, 
Y.M. windows pop in front - while still in full screen!.

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

        As I said, app_server can't do something about this. If you ask me, 
this can only be (IF it can) solved at driver level.

> Thanks for reading :)

        Thanks for giving. :-)))


Bye,
Adi.

Other related posts: