[interfacekit] Re: PortThief

Something that occured to me:  where does calling the various graphics 
driver hook functions come into this?  Given that they are surely used, 
it seems more likely that the current app_server clips the drawing 
commands and then calls the driver add-on (or some intermediate proxy) 
to do the rendering -- either through accelerated functions or straight 
to the frame buffer as necessary -- as opposed to rendering to a bitmap 
and blitting a clipped region to the framebuffer.

Does that seem like a reasonable conclusion, or am I on crack here? ;)

e

>>The server-side of BView, yes?  So the idea would be that the view
>>scribbles on its own bitmap, and the app_server blits an appropriately
>>clipped portion of that bitmap, right?  Sounds like one way to do it,
>Not quite what I meant. When I said the app_server renders on it I mean 
the 
>BView holds onto the bitmap, but when certain calls are made 
(StrokeRect(), 
>etc.), the app_server does the drawing onto the view's bitmap.
>
>>however I'm concerned about the amount of memory needed to maintain
>>bitmaps for every single view, not to mention possible speed issues. 
>>The question is whether executing clipped drawing commands straight to
>>the framebuffer would be faster.  Could be useful for prototyping,
>>though.  I think the thing to do is abstract the actual drawing
>>mechanism; keep it as isolated as possible so that the rest of
>>app_server is protected from our attempts to optimise drawing.
>I haven't researched this bit very much, so I may or may not be correct 
on 
>this. but I think the model used in AtheOS is probably a good way to 
go, 
>which is something like what I described. I like the idea of protecting 
the 
>app_server from the rendering junk internals. I'll keep everyone posted 
on my 
>progress on the graphics crap.
>
>--DW

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: