Just like what Clint described, I get long pauses because competing
pending/resize calls. Sometimes I have to wait many seconds before I get
back the control. Here is what I did to overcome this issue:
procedure main()
w := open("resize", "g", "size=400,400", "resize=on")
width := 400
repeat {
count := 0
while Pending(w) & Event(w) & ((count +:= 1) < 10) # do events in
chunks, and limit to 10 at a time
x := WAttrib(w, "width")
if (width ~= x) then{
width := x
WAttrib(w, "size=" || x || "," || x)
WFlush(w)
}
}
close(w)
end
This runs a lot smoother for me, but it it has the same flaw as before, the
size doesn't change in a predictable way. The resize works sometimes, but
other times I have to click the canvas or do a drag event on the canvas to
make it work afterward. It is like the window attributes are out of sync
with X windows, even though I tried flush/sync/raise while I was debugging
this.
Cheers,
Jafar
On Fri, Nov 11, 2016 at 9:34 AM, Steve Wampler <swamp...@noao.edu> wrote:
> Hi Clint,
>
> On 11/10/2016 08:42 PM, Jeffery, Clint (jeffe...@uidaho.edu) wrote:
> > Your program issuing a resize request for every resize event seems to be
> tickling a pathology of some sort. If you start
> > dragging real slow, it seems to work (at least on my machine) but then
> goes bonkers. Its an infinite loop, since
> > Pending() never fails. But my sense is that after it falls behind a
> certain amount, resize events and resize requests
> > form their own feedback loop. It is either that or some kind of
> competition between the window system and the
> > application, as to who is processing input events, and which window
> retains the focus. It is like: we are having to
> > repaint the window so many times, the window system isn't able to
> continue the drag/resize operation at speed any more.
>
> Interestingly enough, I can't reproduce the behavior you get running on my
> machine. See my response to Bruce for the
> behavior I see. I take it from what you describe that there's not a
> single thread for executing window actions so they
> are forced to execute sequentially
>
> > Feel free to contribute improvements to the C code for handling window
> resizes. It tries pretty hard to do things like
> > suppress adjacent resizes to avoid falling behind, but maybe your
> explicitly resizing in the middle of that defeats the
> > code that is there.
>
> I have a feeling that this is non-trivial, as I expect it does mean
> rewriting the window code so low-level window
> actions are performed sequentially. Given that I haven't written any
> meaningful C code in over 25 years, I'm pretty
> sure I'm the wrong person to tackle this!
>
> Incidentally, I've modified the original code (named by the author as
> 'rosetta_clock.icn' as he wrote it for
> the RosettaCode site) to get around the problem I was having. After
> resizing, if the window isn't square, then
> a simple mouse click in the window will square it up.
>
> -Steve
> --
> Steve Wampler -- swamp...@noao.edu
> The gods that smiled on your birth are now laughing out loud.
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
