All pastes #433609 Raw Edit

Something

public text v1 · immutable
·published 2007-04-10 22:09 UTC
rendered paste body
Hi,

> In wall, we translate and scale painted screen when in expo mode, hence
> > we want to apply these changes to the clip planes, too. Without that
> > (current code), single outputs become blanked under certain conditions
> > (e.g. initiation of switcher in multihead mode).
> 
> I don't understand. The additional clipping planes are used to clip
> window geometry to the output area. The clipping planes are affected by
> any screen transformation you apply and the only time you would have to
> set them up differently would be if you would want them not to match
> your transformations and I'm not aware of a use case for this yet.
> 
Well, I will try if it's really needed in wall, but one use case for that is definitely the 3D plugin (guess you know that one ;-) ) where the windows come out of the screen (are translated in the z axis). Those windows will be clipped when the normal clipping planes are applied. The solution here is to arrange the clipping planes differently (not around the viewport, but tilted so they cross in the center of the cube - I can draw a figure if you like).

> > > - For expo mode, we need a global (not per-output) perspective. We also
> > > > mentioned that before and you said you think it's the best idea to put
> > > > this into the CompTransform struct, right?
> > > 
> > > What do you mean by "global (not per-output) perspective"? The
> > > perspective matrix is currently the same for all outputs. Do you mean
> > > that it needs to be different?  Can you please explain more why you need
> > > this?
> > 
> > We want to achieve that plugins can disable per-output drawing and paint
> > to the whole screen area as if it was one single area. This could be
> > solved either by some flag or by having different projection matrices
> > per output which are adjusted appropriately.
> 
> Can't we adjust the modelview matrix appropriately to get this behavior?
> 
We can do this, but we believe it's far more efficient and straight forward to adjust the projection matrix itself than inverting it and multiplying it with the modelview matrix.

Regards,

Danny