[interfacekit] Re: :) Again - BBitmap

> >     Latency? Please explain. All I can say, is that, we can lower to
> > 0 the
> > time we wait for the (main thread)/(one thread) in my/your solution.
>
> If two threads are involved in drawing to the bitmap at least two
> context switches are necessary until the bitmap is drawn and the
> application thread can resume its work (latency).

    That always happens in case of app_server. Right?

> >     This is not flexibility. :-) This is efficiency. :-)
>
> It's the flexibility to be always most efficent. ;-)

    That doesn't "sound" flexible! :-) It's more of a point.

> >     :-) Flexible would be a fast drawing engine that can do
> > accelerated
> > drawing onto screen as well as into bitmaps.
>
> What I'm proposing still does that.

    Yes, I know.

> >     Because we have 2 methods, it doesn't mean that a better one
> > doesn't exist!
>
> I wouldn't rule out that possibility, but realistically analyzing the
> situation, I wouldn't expect too much.
>(That's why I like mine a bit better, BTW. ;-)

    Me too! But the best result, I think, is by combining the two methods;
because yours may spawn a few threads that actually are not that busy
drawing! ( :-) Dynamic Port [re]Allocation Schema? - see my other email)

> >     7 years have passed since the fist 3D card has appeared! I REALLY
> > don't
> > think that there is someone who doesn't have one! And if it is... I
> > surely
> > don't want to support his needs! This is a Multimedia OS, we have
> > some
> > requirements, don't we?
>
> Sure, I just don't see how this is related.

    A Multimedia OS requires performance, we shall not support old hardware
that doesn't have acceleration.

> You are talking about 3D
> acceleration, while I outlined a simple strategy, that can be used, in
> those cases (not `for those graphic cards') where hardware acceleration
> is not available.

    Sorry, you're right!

> We certainly will. Though I would prefer to have a good solution soon,
> than the best solution half a year later. Mind you, the current goal is
> to clone R5, extending and improving only where really needed or being
> done at very low cost.

    Yes... we will get much criticism from the beginning, and that won't be
that good.

Other related posts: