[haiku-appserver] Re: drawing thread

Hi guys,

I am reading along with this interesting stuff, in order to see if I 
can get some idea of what's going on and how it all might work at some 
point..
I have a remark to make about this locking/doublebuffering/ parallel 
drawing onscreen, that you probably should keep at the back of your 
head:
(I hope one day I'll know what exactly the AccelerantDriver is and what 
BitmapDriver is: I am looking for normal driver parallels of course ;-)


>       It can be seen we haven't talked in a long time. :-)
>       I don't know how double buffering at DD level could work. In fact, 
> I'd really like you to explain 
> us, cause' you're making me very curious.
> 
>       My opinion:
>       I think you are wrong. DisplayDriver is a drawing framework. How it 
> gets things done it's its 
> business, it can directly use hardware acceleration or use CPU to 
> draw in buffers.

-->I am assuming here that these buffers reside on the Graphicscard. If 
not, you can ignore this Email. I am assuming this because the option 
of hardware acceleration seems to exist from the sentence above.
The sentence also implies that both the source and destination of the 
drawing actions are residing on the graphicscards RAM, or acc would not 
be possible (ATM at least).


>       You do not need to lock it to use its methods. Instead, those 
> methods should get a buffer and a 
> drawing context. Based on those arguments, it draws within specified 
> clipping region inside buffer. 
> This way you need not to lock DD, and in a multiprocessor environment 
> is could be a very good thing 
> as another CPU could safely draw onscreen the contents of other 
> windows.


OK, here's my 'warning':
While you are correct in saying you can draw 'parallel' in those 
regions inside the buffer, there may be important performance penalties 
if you don't serialize the access after all. The 'burst mode' of 
writing across the PCI/AGP bus depends on serialized access (at least 
beyond those say 32bytes blocks, within these blocks it doesn't 
matter). Burst mode (fully automatically generated by the system's 
hardware) works in PCI mode, and in AGP mode. In AGP mode bursts are 
the ones being accelerated with the 'fastwrites' feature.

If indeed both the source and destination of the drawing action reside 
in graphicsRAM, this performance issue only exists if you use non-
accelerated drawing actions, because the CPU would need to read the 
data across the PCI/AGP bus, and then write it back, while the 
acceleration engine keeps it local on the graphicscard RAM.

---

About optimisation of stuff: I want to share my personal findings about 
this with you:

I have found that it's _very_ hard to optimize for speed if you have 
not looked at the problem at hand from every viewpoint, and with every 
possible aspect in mind. From my 'warning' stated above might see it 
will largely depend on the actual _complete_ 'architecture' you use. 
Modifying seemingly small details might completely reverse the results 
you get from a certain way of doing things.

So, my normal way of going about things is: just keep on coding until 
you have seen the whole thing. Once you have it complete, you can 
finally correctly analyze every aspect of it, and then redesign/
optimize (parts of) it. Of course, I am working with hardware, which 
means, that I don't have the option of designing a architecture myself. 
I just have to grasp how and existing hardware architecture is setup, 
and _then_ correctly design and code the software for it.
Still, I think even for software-only projects this partly applies, as 
you might not have thought about every aspect you are going to need or 
you will encounter, untill you complete the job. Finding out at a later 
stage that some seemingly detail works different than you thought, just 
_might_ render the optimisation done before completely useless. 
Speedwise things especially I guess, as you are still on hardware ;-)


----

OK, just my two cents. Do with it what you will :-)

Best regards,

Rudolf.

Other related posts: