--- Michel Dänzer <michel@...> wrote:
> On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
> > --- Michel Dnzer <michel@...> wrote:
> > > On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
> > > > Attached is a screen shoot of the effect of adding 1024 to the
> > > > ColorOffset.
> > >
> > > It's hard for me to recognize anything; can you describe your
> > > observations?
> > >
> > The data was shifted to the right, making it offcenter. I will need
> > find a way of undoing/compinsating-for this inorder to make changing
> > offset usefull.
> I guess you need to compensate the GL viewport (I guess you may have
> talked about that in earlier posts? I somehow thought you were talking
> about the X server viewports).
I try to keep each paragraph on topic, however this thread all started
with MergedFB. So I see where you could have gotten confused. What
should we call the 3dOutputClipRects?
I don't think I ever thought it would be a problem. Only after I found
this did I start playing with multiplexing the acctual cliprects. As now
I can see that I might need the segragation to this extra trickery.
Speeking of multiplexing the cliprects, I can't seem to find where they
get created(on move/resize)? I made the lock contection(where the
move/resize client code is) recompute the cliprects. However my work gets
undone on every move. numClipRects as well as pClipRects gets resert,
where dose this happen?
> > > > I still have to find where rmesa->state.color.drawOffset comes
> > > and
> > > > what effect the first 4 bits(define RADEON_COLOROFFSET_MASK
> > > > 0xfffffff0) are for
> > >
> > > The 128 bit alignment.
> > >
> > The value is in 8bit bytes then? not pixels. What kind of conversion
> > I have todo, 24bpp = 4 bytes right?
> screen->cpp contains the number of bytes per pixel.
I'm assuming screen part of rmesa.
> Earthling Michel DÃ¤nzer | Debian (powerpc), X and DRI
> Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.