Hi folks,
as the font bug I already reported earlier started to get really bothersome
when I updated the widget lib to cope with the new font sizes, I tried
to investigate it.
However I don't quite a) understand the code and b) know the place where
stuff gets messed up.
I have for test purposes reverted that complex loop with the ands and ors
to a more simple one, that will build a ggi_color buffer from the bitmap
data.
However it doesn't quite change the problem.
Observations:
- when I replace the bitmap-data with something else, like a crosshatch
calculated at runtime, all is well - every letter comes up as a
crosshatch
- when I read out the fontimg stuff, it only works up to a given character
that must be near the Z->a transition (i.e. small chars don't display
right, just rubbish).
- However it seems that redraws will correct the problem. Possibly
because then the XDrawString stuff gets used which works right.
Questions:
- Why do we use that complex X font structure which will also cause problems
for depths below 8, when we could just convert it once and for all
in misc.c to a bitmap format of our own?
I do not see performance problems, as in the current version,
ggipackcolors gets called twice (o.k. with probably easy cases), then
the stuff gets mangled and then blitted.
What I'd do is I'd _build_ the character in a ggi_color array, pack that
and blit it. That would always work, regardless of depth, and be much
easier to read.
- Any pointers on where the font XImage gets messed up? Maybe something
is clipping? Wait ... checking ... STRIKE!
When you open the X window wide enough, all is well. I just tested with
width 1024 => correct display. However I suppose there are still
errors, as 6*256=1536 ... but I don't use that chars in the demo ...
Testing further ... Yes. Confirmed. At width 612, Stuff from 'f' on will
be destroyed.
- So what shall we do:
a) shall we move to the IMHO simpler method sketched above?
b) How shall we solve the clipping problem? If we do a), it should be
simple to have the caching in misc.c modified so that it will
render single characters and combine them into our cachemap.
c) Shall we compensate for the paranoid case, where even a single
character would be clipped due to a very small window size.
A few other observations WRT the new X target:
- Input events now only come from inside the displayable area. This is
disturbing for me in 2 cases:
a) I cannot move the cursor to a border to have it out of the way and
still send keys to the app.
b) When using libggiwmh to make the window resizeable, the newly
created area will not accept events until the window is resized
with a setmode.
- When using setmode to resize a window, it seems to be newly allocated.
This causes windowmanagers to start a new placement calculation.
Thus when resizing the window jumps around.
I have for now worked around it using wmh which reduces the annoyance
to the newly sized window briefly appearing somehwere (random placement
is on) and then reverting to its original place.
Comments, suggestions?
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
