http://bugzilla.suse.com/show_bug.cgi?id=941931 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jsrain@suse.com |mchang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c2 --- Comment #2 from Michael Chang <mchang@suse.com> --- Hi Jan, Can you please test by disabling theme and with gfxterm and background ? It's simple to do that by editing /etc/default/grub and commenting out the GRUB_THEME=.. GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png # GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt After that, run grub2-mkconfig -o /boot/grub2/grub.cfg I think we need to check whether it's related to how grub's theme rendering and compositing things to target . And if you still experience slowness with gfxterm, I suspect it's more related with firmware as the flipping to front/display buffer is somehow slow in larger resolution.. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c4 --- Comment #4 from Jan Matejek <jmatejek@suse.com> --- sorry, a correction. text does NOT appear instantly, but is rendered along with the border. (just confirmed this by switching to grub's edit mode. the screen is cleared and then a new border with the edit window is rendered, again, scanline-by-scanline) (a clarification, when i say "line by line", i mean scanlines, as in individual pixels. not lines of text) it very much looks as if a pre-filled 2560x1440 buffer is copied on screen and that takes a long time. moving around and editing is responsive, which i guess is because a much smaller area is updated? it still feels sort of sluggish, but at this point i can't be sure whether there is a problem or whether my perception is wrong. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c6 --- Comment #6 from Michael Chang <mchang@suse.com> --- (In reply to Jan Matejek from comment #4)

(a clarification, when i say "line by line", i mean scanlines, as in individual pixels. not lines of text)

it very much looks as if a pre-filled 2560x1440 buffer is copied on screen and that takes a long time.

That sounds like no dobule buffering so that the rendering direct updating the on-screen buffer in video memory, blitting data from system memory to it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c7 --- Comment #7 from Jan Matejek <jmatejek@suse.com> --- (In reply to Michael Chang from comment #5)

(In reply to Jan Matejek from comment #4)

From your log. somehow the active video adapter was VGA Video driver.

no, the top of the output is missing and the list of resolutions is apparently generated by "VESA BIOS Extension Video Driver" (i presume the "VGA" entry means that the VGA driver was loaded, but found no applicable resolutions?) anyways, i'm attaching a complete output that I got when only vbe was loaded.

function load_video { insmod vbe }

this didn't change anything (except the VGA section from vbeinfo is gone) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c9 --- Comment #9 from Jan Matejek <jmatejek@suse.com> --- Created attachment 646061 --> http://bugzilla.suse.com/attachment.cgi?id=646061&action=edit hwinfo --framebuffer output -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c11 --- Comment #11 from Jan Matejek <jmatejek@suse.com> --- (In reply to Michael Chang from comment #10)

Looks to me that the video ram is too small to enable page flipping by swapping poiners of on-screen and off-screen buffers in video memory to update the screen quicky [1].

this is true, but doesn't help the issue indeed, lowering to 1600x1200x32 (6400 line width, 15MB used) gets rid of the line-by-line rendering, and the whole image appears at once BUT, there is still roughly the same delay before the image appears so ISTM it's the filling of the buffer itself that is causing the slowdown -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=941931 http://bugzilla.suse.com/show_bug.cgi?id=941931#c13 --- Comment #13 from Jan Matejek <jmatejek@suse.com> --- so, some measurements. taken with a stopwatch in my phone so sub-second precision is going to be wobbly timed from the moment when "Loading GRUB" in 80x25 textmode flashes on the screen and immediately disappears at 1920x1440x32 (does not fit double-buffer, rendering is visible) themed GRUB takes 4s to render the screen, and 1s to switch between items (i forgot to take note what happens when an item is selected; it's probably not significant, perhaps it disappears immediately) gfxterm GRUB with no background takes a little less, maybe 3-3.5s to render the screen. switching between items is immediate after selecting an item, takes another 3s to "de-render" the screen, clearing it line by line, before boot starts at 1600x1200x32 (fits double-buffer, screen displays at once) themed GRUB takes about 3.5s to render, around 0.7s to switch between items (again, not sure what happens after selecting item) gfxterm GRUB with no background takes a little over 2s to display after that, additional 2s before it starts responding to keyboard input switching between items is immediate, booting is also immediate the additional delay *seems* to correspond to clearing the second buffer in advance? presence of background image doesn't seem to have an effect when double-buffering; i didn't take measurements with it, but it didn't feel that removing the background image made it faster. when not double-buffering, the background image takes its own time to render, but doesn't "de-render" like the gfxterm border and instead stays on the screen as if in background layer, presumably until the kernel takes over -- You are receiving this mail because: You are on the CC list for the bug.