On Monday 15 February 2010, Zack Rusin wrote: > On Sunday 14 February 2010 18:24:51 Marco Martin wrote: > > > QRectF makeUniform(const QRect &orig, > > > > > > const QRect &dst) > > > > oring and dist shouldn't them be QRectF in the signature? > > only if we care about it being anywhere close to correct. definitely should > :) > > > ok, let's see if i got what this does :) > > if an element has the geometry(10.5, 10.5, 30,30), we want to render it > > at (0,0,30,30) we'll render at (0.5, 0.5, 29.5, 29.5) making aligned > > the edge > > > > in the oringin that would otherwise have been rendered between two > > pixels > > > > but don't quite understand why the size gets changed? > > it shouldn't. i should've used moveCenter or such. the size should stay the > same, we just want to align it. basically just do the best we can within > the size that we were given.
ok, with those two changes things are much more clear ;) > all in all the size could and possibly should be changed by the offset > itself, but that could be fixed later. yeah, worth a try > so as you mentioned, it's easiest to see within identity transform: > orig = QRectF(0.5, 0.5, 32, 32) > dst = QRectF(10, 10, 32, 32) > hence transform = identity, offset = 0.5 and so > true dst = QRectF(10.5, 10.5, 32, 32); > > with scaling things get hairy, there are two possibilities here they are: > true dst = QRectF( > offset * div_w + dst.x(), > offset * div_h + dst.y(), > dst.width(), dst.height()); > and > true dst = QRectF( > offset + offset * div_w + dst.x(), > offset + offset * div_h + dst.y(), > dst.width(), dst.height()); will try both :) > (btw, in res.adjust in the last email instead of "offset / div" it should > say offset * div). > > for the case above that would be: > orig = QRectF(0.5, 0.5, 32, 32) > dst = QRectF(0, 0, 16, 16) > hence transform = scale(0.5, 0.5), offset = 0.5 * scale = 0.25 and so > true dst = QRectF(0.25, 0.25, 16, 16); > or > true dst = QRectF(0.75, 0.75, 16, 16); > > the code i've sent in the other email does the first, but it's possible > that #2 looks better or as mentioned in the last email it's possible that > just skipping the divisor looks ok so i'll try both and see how it looks > true dst = QRectF(0.5, 0.5, 16, 16) > but i sorta doubt that because mathematically it doesn't seem to make sense > to me, but hey, when it comes to esthetic's lots of things doesn't make > sense to me. eh, usually are the matematically correct things that are pretty, somtimes the utterly irrational too ;) Cheers, Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
