I using gs:check-event with the (gs:get-bounds) call every 100 millisecs to know if canvas has resized.
In my system (AMD Turion 64, Debian 64 bit) newlisp, runned with guiserver uses ~55% CPU for newlisp and ~45% CPU for java.
The CPU's adaptive fan is trying to fly away from the box :-)
Can this be optimized?
sample code:
(gs:init)
;;;; describe the GUI
(gs:frame 'PFrame 100 100 600 600 "Frame")
(gs:set-border-layout 'PFrame)
(gs:canvas 'Picture)
(gs:set-background 'Picture gs:white)
(gs:add-to 'PFrame 'Picture "center")
(gs:set-visible 'PFrame true)
(define (bounds)
(2 (gs:get-bounds 'Picture)))
(define (handle-resize)
(set 'new-bounds (bounds)))
(while (gs:check-event 100000) ; check for 10 milli seconds
(handle-resize))
Yes i have the same with my AMD 64..the fan is blowing crazy on some applets.. on my P4 is too quiet but same cpu load..
The most performance goes into the interaction part between Java and
newlisp. I forgot the tool name but you can debug java and see the
performance details in java while running a GS applet.. Because running
java allown on my machine is as quiet as a mouse..
But perhpas lutz has an idea?
We need a resize-event (like a mouse or keyboard event). I think there is one, which could be implemented. Anything polling is too CPU expensive.
Lutz
Hi, Lutz!
Resize event should be a good thing.
But there is one issue there (just discovered):
On my system (gs:check-event pause-in-microseconds) seems not to wait at all despite the pause value.
I.e. for 10 seconds I got about 200000 events.
Probably I need a manually inserted sleep in the event loop?
Yes, slow it down with (sleep ...). The time in 'gs:check-event' is the maximum time it will block before returning and looping. This is similar to a 'net-select'. So if there is an event before the wait time, it will return right away and the loop will go faster.
Lutz
Will sleep in a loop block handling of the "hooks", attached to the buttons and other objects?