[MPlayer-dev-eng] Direct3D OSD discussion

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Mon Dec 8 19:57:53 CET 2008


On Mon, Dec 08, 2008 at 08:39:21PM +0200, Georgi Petrov wrote:
> > The priv->locked_rect is locking a surface the size of the playing video
> > , and the local locking is for the size of the display.  So in this case
> > it is not a 'shadow' of the other lock, as the parameters are different.
> 
> Yep - there's real problem. I mean just "name shadowing". Never mind.

Just a minor note: the term "shadowing" means that you can not access the other variable,
which is not the case here (and gcc would warn about it).

> I means that the both code snippets translate into the same ASM
> instructions, right? I hope the compiler doesn't do something
> dynamically for each from iteration when the pointer is declared
> inside it.

That would just be a lot of pain for no advantage, compilers always
allocate the stack frame (i.e. the memory for all stack variables) at
the start of the function, no matter where they are declared.
At -O3 it might do some useless assignments, but at higher optimization
levels that should not matter either. Also performance is not that
critical here, it's done only once per line, not per pixel.

> I see. The memory after each line (if pitch > width) is reserved for
> cache, so you delete it as well. I'm sure there are no problems with
> that, I just wanted to make sure you know about it.

"reserved for cache"? Anyway it is just completely ordinary memory,
that's exactly the point of it, to allow processing each line e.g. with
operations that always process full 16 bytes (some DMA controllers) etc.

Greetings,
Reimar Döffinger



More information about the MPlayer-dev-eng mailing list