[interfacekit] Re: :) Again - BBitmap

On Fri, 25 Jul 2003 11:18:57 +0300 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
> > >     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?

Yes.

[...]
> > >     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)

Well, the whole computer is rather idle most of the time. Our 
particular aim is not to save as much resources as possible, but to 
solve the problem, that with a, in itself, relatively cheap resource 
like a bitmap, you can easily make the app server run out of resources. 
A reasonable limit, like 5 or so, threads for bitmap drawing per 
application sounds like a good strategy to me. Then even with 20 
application, each hitting the limit, the app server should be fine.

> > >     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.

I wouldn't be so radical. To have a fallback shouldn't do harm, I 
guess. :-)

[...]
> > 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.

As long as we do it at least as good as R5, noone should have a reason 
to complain. And I'm sure, a lot of things will be better than in R5.

CU, Ingo

Other related posts: