[interfacekit] Re: :) Again - BBitmap

>  wrote:
> > > >     So, if understood corectly, drawing on application side, by
> > > > acquring the
> > > > lock that the graphic card driver holds, involves a lot of
> > > > context
> > > > switching
> > > > at that low level, and, as I see the things, that is not quite so
> > > > good as
> > > > letting only one context switch for the app_server to draw in the
> > > > name of
> > > > all threads.
> > > >     Don't you?
> > >
> > > No, all I'm saying is, that drawing into non-off-screen bitmaps
> > > application side results in a lower latency, since doing it in the
> > > app
> > > server requires context switches (and mode changes for the
> > > communication).
> >
> >     non-off-screen bitmaps? that means... on screen, and that under
> > no
> > circumstance I agree. Maybe you wanted to say: drawing into off-
> > screen
> > bitmaps application side ?
>
> I mean by non-off-screen bitmaps those, that don't have the
> B_BITMAP_IS_OFFSCREEN flag set, i.e. those whose bits reside in main
> memory. Sorry, if that caused confusion.

    Ok that's better. :-)

>
> >     And... to reformulate my earlier question: Is it equal good to
> > have
> > context switching at server side or at driver side? Isn't the one at
> > driver
> > side more costly?
>
> I actually don't get what you mean by context switching on driver side.
> If a thread from another team is scheduled, then a context switch is
> done.

    But,... that's does not happen in app_server, all threads have the same
team.

> For a syscall (including driver calls through ioctl()) only a
> mode change is done.

    I'm talking about cloning accelerants. One for every application that
uses off-screen bitmaps. Every one of them, have to wait for a lock from the
driver. Isn't this context switching? Is it more good at driver side? 'Cause
IHO, it isn't - if app_server were to draw in off-screen bitmaps, then. no
context switching would be done.

Other related posts: