Page MenuHome

UI: Splash Screen Refactor
ClosedPublic

Authored by Harley Acheson (harley) on Mar 3 2020, 1:14 AM.

Details

Summary

Our project contains two versions of the "splash" image, but one can be removed. Yes, this proposal will seem counter to some readers' assumptions, but bear with me...

With the current splash screen we start with a large version of the image ("splash_2X.png" at 1002x500). And then we make a lower-resolution version (501x250) using an external program (imagemagick). And then we include BOTH versions in the project. We then display the smaller version when scale is 1X (or smaller, which never happens) and the larger one is used at all other times and scaled to fit.

The intention of having two versions like this is to have a nicer result, but that is not the case. Instead we have a nicely resampled image at 1.0 and a native image at 2.0, but in between (and above and below) we see a fairly badly resized image.

This patch makes it so that only the larger image is ever used, but it improves the resizing. The end result is that the we obtain a result that is indistinguishable from current at scales 1.0 and at 2.0. But at every point between, above, and below are all better. And we lose the complexity of dealing with multiple image. And we save 205K from the project if we do not include the smaller image.

Following is a comparison at 1.0 scale. Current on the left, patch result on the right. You'd be hard-pressed to find any difference.

At 1.3X scale it looks similar, but if you look closely at the blender logo and awards, the right side is better.

At 2.0 scale they look virtually identical again (current on top, patch on bottom)

At 2.1X scale you see large differences with the current (top) showing odd artifacts on the logo and sheering in the award borders. The bottom is perfect.

So, as illustrated, we have one less file, have better results in the majority of cases, and never have worse result. And as a bonus the splash image is auto-sizing. So no matter what size image you put in there it will be scale to size, keeping proportions properly. Here is an example with the splash image swapped out for one that is 1920x1080p. Because the image is slightly taller the splash dialog is just a touch taller too. Shown here at 1.5X scale.

Boring technical details:

  • Adds a uiDefButImage() helper function for making uiBut of type UI_BTYPE_IMAGE, in a way that we can override the color if desired.
  • ui_draw_but_IMAGE() is altered to scale the image to the target size before drawing.
  • wm_block_splash_image() altered to only use datatoc_splash_2x_png, and not do any checks for size or proportion.
  • wm_block_create_splash() takes the image, scales it to our desired width, keeping the proportions of the image.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) edited the summary of this revision. (Show Details)
Harley Acheson (harley) edited the summary of this revision. (Show Details)Mar 3 2020, 1:17 AM

The smaller image is generated from the larger one anyway, so if the scaling looks good, as it indeed seems to do, then I agree there seems to be no good reason to keep both image resources. The auto-scaling is a bonus as well.

This revision is now accepted and ready to land.Mar 3 2020, 9:42 AM

Updated to reflect current state (and recent changes) of master.

Updated to current state of master.

Updated to current state of master.

@Julian Eisel (Severin), can you look at these splash screen patches? I'm short on time for 2.83.

Julian Eisel (Severin) edited the summary of this revision. (Show Details)

Fix warnings and add comment on possible caching improvements

I think this is fine, although there's one note below. I will prepare a commit to remove the second splash image and adjust naming accordingly. So this can go in tomorrow for 2.83.

This re-reads and re-resizes the image buffer on every(!) redraw of the splash.
E.g. using the full render of the old splash (F8473033 - a 7500x5000px image) makes Blender unusable while the splash shows.
Of course that's not something we'd run into often (although app templates support custom splashes, so people will use too big images for splashes). But with lower spec hardware there may be some slight lag with more reasonable sizes even. So good to keep an eye open for complaints/reports about performance here. It should not be quite simple to add cashing for the scaled image buffer in future.

@Julian Eisel (Severin) I will prepare a commit to remove the second splash image and adjust naming accordingly. So this can go in tomorrow for 2.83.

Thanks!!

This re-reads and re-resizes the image buffer on every(!) redraw of the splash

Although not continuously of course. It is basically called once any time you move your mouse in or out of the area, when you hover over a button, etc. So typically that function is called 2 or three times when you bring up the splash. But if you try hard you can get it called as often as a couple times a second. In a typical case where the image of a reasonable size that entire function (wm_block_create_splash) runs in 17ms on my old computer while in debug mode.

using the full render of the old splash (F8473033 - a 7500x5000px image) makes Blender unusable...So good to keep an eye open for complaints/reports about performance here. It should not be quite simple to add cashing for the scaled image buffer in future.

Yes, for sure. We could cache it, or give an console message if over a certain size, or even just refuse to load their image if over a certain file size.