GNU bug report logs - #38497
27.0.50; Frame is not rendered when frame-resize-pixelwise it 't

Previous Next

Full log

Message #35 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 08 Dec 2019 17:21:22 +0800

> How do you create such a frame in the first place?

Originally, I observed the issue with my org-capture frame (I am using
org-capture-pop-frame package) when it was called in a tile window
layout. In my machine Meta-c is simply bound to

bash -c 'emacsclient -e "(org-capture)"'

The default emacs frame is just around a quarter of screen size (as it
appears in floating window layout) and I can sometimes see it appearing 
for a split second in a tile layout before being resized.

Also, as I showed in emacs -Q recipe, failure to redraw the frame
can also be triggered in a maximised or a full screen emacs frame. The
frame is also being resized there, though it is much less noticeable
(just closing small gap below the maximised frame). 

> Unfortunately, that patch breaks pixelwise resizing.  The frame could
> then be resized only in character size increments, defeating the entire
> original purpose of 'frame-resize-pixelwise'.

Sure. Just wanted to document the minimal change required to make the
bug disappear. 

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  >> ... If not, can you tell me the four values here
>  >> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
>  >> FRAME_PIXEL_HEIGHT (f) and pixel_height.
>  >
>  > Not sure how to get those.
>
> By running Emacs under the debugger and putting a breakpoint at that
> position.  But let's put that aside for the moment since, as you say,
> this part is not the real cause of the problem anyway.
>
>  > Actually, this piece of code seems to be a more specific reason
>  > triggering the bug (see the relevant patch attached - that patch makes
>  > the bug disappear).
>
> Unfortunately, that patch breaks pixelwise resizing.  The frame could
> then be resized only in character size increments, defeating the entire
> original purpose of 'frame-resize-pixelwise'.
>
>  > I tried your suggestion (no idea how it is different from original code
>  > though). It makes no difference.
>
> I would have been surprised if it did.
>
>  > A possible hint to why this code fails to resize the frame is that my
>  > WM resizes the frame as soon as it is created. It is not a gradual
>  > resizing with mouse, but rather instant resize to pre-calculated size
>  > (according to layout). I can sometimes even see the frame being created
>  > with much smaller size for a split second followed by resizing it to
>  > target size.
>
> How do you create such a frame in the first place?
>
> martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.