retrofax / garglk

Automatically exported from code.google.com/p/garglk
Other
0 stars 0 forks source link

Resizing a window with a large scrollback is very slow #135

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Using latest svn r463

What steps will reproduce the problem?
1. Start a game and press ENTER for about 30 seconds to fill the buffer.
2. Resize the window width by a pixel or more.

What is the expected output? What do you see instead?
The window becomes unresponsive for about 15 seconds on my machine.

Please provide any additional information below.

I realize this is hard to optimize, but maybe there are other solutions, like 
not reflowing if the scrollback is too long.

Original issue reported on code.google.com by saltyho...@gmail.com on 23 Nov 2010 at 8:30

GoogleCodeExporter commented 8 years ago

Original comment by bcressey@gmail.com on 23 Nov 2010 at 10:48

GoogleCodeExporter commented 8 years ago
I suppose this is the same problem I've got. I have two released project and an 
I6 library extension using "dynamic" graphic windows at the sides of the texts; 
whenever an image is placed on screen or removed (therefore resizing the main 
text buffer window), the game became locked for a while (something like 3-4 
seconds, at worst). Graphic windows above the text obviously doesn't have 
problems.
The games runs well on other 'terps (but I keep packaging them with Gargoyle, 
and suggesting Gargoyle as a first 'terp choice).
I'd prefer to have the scrollback optionally turned off, or a shorter 
scrollback, or a scrollback buffer size set in garglk.ini, if this can help 
(and I suppose it does).
bye

Original comment by plucche...@gmail.com on 12 Feb 2011 at 4:27

GoogleCodeExporter commented 8 years ago
I've adjusted the behavior in r515. Now lines beyond the initial scroll buffer 
size (512) are discarded during reflow operations.

A better fix would involve reflowing only as much text as can be displayed in 
the newly resized window, saving the rest of the work for when the player 
decides to scroll through earlier output.

This requires more sophisticated layout code but should be possible in the near 
future.

Original comment by bcressey@gmail.com on 22 Feb 2011 at 11:26