| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1627
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | Strange behavior wih drawimage() |
|---|
| Version: | 2.0-current |
|---|
| Created By: | jasonsewall |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | jasonsewall
13:52 Mar 06, 2007 |
| I'm making a custom widget and I'm finding drawimage() to have very inconsistent performance.
I'm not familiar with the backend architecture of fltk's drawing functionality, so the behavior seems like a bug to me.
I'm procedurally drawing the contents of this widget into a buffer, then displaying that buffer with drawimage. This happens whenever the user provides input to the widget, say by dragging the mouse.
What I'm seeing is that my procedural code takes a pretty consistent amount of time - 0.05 seconds for a given size, for example. For that same size, the call to drawimage() takes around 0.0006 seconds, but only for a few frames. After about 10 frames or so, the time for a call to drawimage seems to skyrocket to 0.2 seconds or so.
This clearly has implications in terms of interactivity. I'd like to be able to update this widget interactively, but the unpredictable behavior of drawimage() is a problem.
Is there a simple explanation for this behavior? Is it to be expected, as the result of some sort of buffering process?
I'd rather not have to use GlWindow for this, for no other reason than to avoid the dependency.
Thanks for letting me know your thoughts.
Jason
P.S. Setup is FC6 (kernel-2.6.19) with g++ | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
