[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: pixeladjust
From:       Jaymz Julian <jaymz () dspaudio ! com>
Date:       2002-08-26 16:44:39
[Download RAW message or body]


> > I'm wondering exactly what I lose by turning off the pixeladjust stuff in
> > kword for my own purposes... I'm aware that it helps with wysiwyg, but
> > exactly how?
> By painting things at the place they are supposed to be (according to the
> pre-calculated hi-res layout). The problem being that when painting, we use
> a different font, which has different metrics (not truly proportionnal), and painting
> N chars at a time can lead to a slightly different position than expected
> (rounding error, in a way, simply due to the integer font size used when painting).
> So we only paint together chars that will appear at the right position when
> doing so (i.e. the chars with the same 'rounding error', aka pixeladjust)

Okay, this is what I'd guessed, it just didn't look that way on my display
^_^.  That is indeed a weird thing to have to do... heh, it's
"issues" like that which make me think that the correct solution is to
reimplent X :-p.

> > b) making it call paragDrawString on almost a per charecter basis instead
> > of a per line basis
> You're using a font that scales very bad then. Ah, no Xft, right?....

Arial [Xft] from msttcorefonts, fwiw.  Ironically, would you believe, zoom
mode actully looks okay with the pixeladjust stuff on a non-xft system for
me.... go figure.  Perhaps it's something to do with my
xserver/display/whatever (i'm running an xinerama based setup, which
messes with the X aspect of some stuffs, so who knows.  it shouldn't
matter, but who knows ^_^)

> > (my current hack, based on QPicture, works much better
> > with the latter, since there is some static overhead in drawing a
> > qpicture, but we all know that qpixmap is useless ^_^)
> You're drawing text using QPicture? Interesting.....

It seemed to be the only widget that would actully do the job I wanted...
(where 'i' is actully defined as 'the people whom i work with who decided
that i should just hack something that works rather than solving the
problem correctly so that they can get me doing other things already'
:-p).  

> > . o O ( and yes, i know that isn't the correct solution either, but I
> > started working on the correct solution, which drawing on a line by line
> > basis, and turned out to be far more work than I have time for right now
> > :( ).
> Keeping a pixmap of the whole line, you mean?

well, what I *should* be doing, is modifying the renderer to only draw
lines which have changed, like it only draws from line n now with your
changes from ~2 weeks ago, since the caching code is, at this point,
getting far more complicated than I am am comfortable with, not to mention
that there is then the overhead of drawing the QPictures directly.

There is, however, complexity with this... basically it requires
re-arranging the code so that the current drawing line gets cleared from
KoTextParag::paintDefault rather than KoTextDocument::drawParagWYSIWYG,
which seems to me to involve non-trivial amounts of work, and (as everyone
has probably noticed ;) I'm a reasonably medicore (some say bad, but hey,
I'm an optimist :-p) programmer who is still getting his head around the
koffice codebase *^_^*

That said, you have given me an idea as to what to do about my prediciment
as it stands now, which is move said code up a level, and cache *lines*
using a qpicture in void KoTextParag::paintDefault, will work now, whereas
it wouldn't under the old caching architecture), and would make this
problem pretty much null and void (not completly, of course, but it'd be
a significant improvement).  who said the code cleanup didn't buy me
anything? :-p.

	- Jaymz

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]