Re: to be effcient or not to be efficient

* Attila Kinali <[email protected]> [2004-01-07 13:39:09 +0100]:

<snip>
> Yes, but if you seek extendability, you still don't need ebml.
> You can do this just with normal structs, w/o any overhead beside
> some pointer arithmetic, which is are 1-3 asm instructions compared
> to a few hundred to thousand you need for ebml parsing.
ACK.
If we really need a complete new interface, we just put wrappers between
new and old one. They can perhaps be generated automatically.

> No worries, all good coders i know learned everything themselfs.
ACK.

I personally see the big problems w/ CS students especially here
at the university in Ilmenau - they simply cant code. Well, if they're
told that the only good programming language is java (and perhaps a 
little bit of haskell) and evrything beyond is "unclean", well what
should we expect ? But the quality of education had become miserable
here by the way ...

<snip>
> If you mean the output modules, than you should reconsider it.
> A video player wants as much buffer from the hardware as it can get
> because it doesn't cost anything to use it (unlike self build buffers
> in RAM). A interactive application on the other hand wants to minimize
> overall delay and thus keeps those buffers small. IMHO the amount
> of buffer in the output modules should be controlled by the application
> and not by the API.
ACK. 

Maybe the API _may_ provide some helper code for buffering, but really
optional.

<snip>
> Yes i asume that there is enough CPU and I/O power to handle the
> stream at realtime. Because otherwise i can clearly forget to 
> watch a movie. If you think about preprocess the images and store
> them until they are showed you go the same way as Nick Kurshev with
> mplayerxp. IMHO it's a good idea and may help in cases where no
> direct render is available and you are at the edge of the needed
> computation power, ie you have enough cpu/io to process the stream
> but at some scenes you're slightly under powered. But, you also
> lose the power of direct rendering and get a lot of io by the
> additional memcpy you have to do.

Well, couldnt such a cache be just one filter in the chain ?
If some really wants this, then he should drop it in and become happy.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/