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.