On Sat, 18 Jan 2003, Andreas Beck wrote: > - 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?
The X font structure is used so that the backbuffer can be updated to mirror the front-buffer even though the front-buffer is drawn with the XPutString primitive and the back-buffer is drawn directly. Unfortunately there's no way to call XPutString on a RAM buffer. In order to do it the other way and still use XPutString, we would have to somehow install our bitmap font into the X server. I seem to have either accidentally deleted or never received your original bug report... could you send another copy so I can investigate it and see if I can replicate it? > - 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. I'll try to replicate this. One other bug I have not been able to track down is that the first puts when you run demo has dots at the lower right corner of each charcell, but from then on everything seems to behave. > - So what shall we do: > c) Shall we compensate for the paranoid case, where even a single > character would be clipped due to a very small window size. > - 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. I think this is a WM problem, but that of course doesn't get us off the hook for fixing it. I haven't looked intpo it deeply enough to propose a solution... I thought I had improved it a while back by changing the window from which events are received to be the parent window, but I'll have to check the CVS logs to verify if that ever got committed. > - 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. Yeah, that's marked TODO in the code (reusing windows rather than destroying them.) -- Brian
