Good morning all,
I have just run another test in which I simply doubled up the Wattrib().
Even though, it still occasionally will exhibit the problem, it
stabilises fairly quickly (less than 1 sec). On some occasions, the
display will have the starting size and on other occasions it will have
the finishing size (when the problem exhibits itself).
I still only get the problem if the movement is a quick flick and
release, so I don't know why there would be a difference between Steve's
system 64 Centos 7 and mine 32 Centos 6.7. Unless, it is related to the
fact that my system is much slower overall.
I will try a test later today with seeing what events are seen in the
unicon program. There may be some obvious problem when this is analysed.
If I find anything, I'll get back to the list.
regards
Bruce Rennie
On 12/11/16 05:04, Jafar Al-Gharaibeh wrote:
> 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
> <mailto:swamp...@noao.edu>> wrote:
>
> Hi Clint,
>
> On 11/10/2016 08:42 PM, Jeffery, Clint (jeffe...@uidaho.edu
> <mailto: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 <mailto: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
> <mailto:Unicon-group@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/unicon-group
> <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
------------------------------------------------------------------------------
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
