We can't use deprecated functions. If you want to replace it, replace it and delete the old function. But don't do half the job and expect a clean build!
The purpose of the shape caching is essentially to allow multiple draws to consecutively add to
previously drawn content. It essentially adds another condition for clearing the texture prior
to rendering.
I also moved the shape list handling into the draw function itself so it's only executed once
if needed instead multiple times when calling functions like set_variable - not that it actually
would have done anything after the first call, but this allows me to keep the clearing-the-texture
code in one place.
Not completely done yet, still need to get some stuff working, but this gets rid of the old commented-out
code and puts stuff mostly in the right place.
Instead of using the minimap surface method (which was getting converted from surface to texture every
draw cycle since the caching mechanism the canvas implemented wasn't available and the weird custom
cache the widget implemented itself didn't seem to do actually do anything) we use the new render-to-
canvas-texture method which is a lot cleaner and should be a lot faster. This also means we no longer
override styled_widget::impl_draw_background.
Do note I might use the design of the removed cache here to add some age functionality to the
font::pango_text cache.
Previously widgets that wanted to implement custom drawing behavior overrode styled_widget::impl_draw_background
or impl_draw_foreground. Those functions in the base class simply called the canvas render methods. Some widgets
such as the minimap ignored that rendered the contents on their own.
This new method allows rendering directly to the canvas's texture, meaning all the caching and sizing is already
handled by the canvas and doesn't need to be done by the widget; everything's always the right size and redrawn
when necessary.
I've left the old getMinimap function alone and added a new function that will eventually replace it
that utilizes texture rendering to a given texture instead of relying on surface blits and scaling.
This has the benefit of, well, reducing surface ops, for one, as well as removing the need to create
a new texture from the minimap surface every time it's updated.
Instead of throwing out the cached texture every time the canvas was dirty, I've added a flag so that
only happens if its size has actually changed. There still seem to be some issues in GUI2 where canvas
objects keep getting reset, but I'm not sure why. Will have to look into that.
Anyway, the addition of the SDL_RenderClear call also seems to have fixed the weird graphics bleed-through
I was getting when running the game with the OGL driver.
I don't know if the canvas copy or move ctors are needed for anything. I added them for a test, but I'll
leave them for now in case I need them later.
* Removed display::screen_area(), display::w(), and display::h().
* Moved the global screen_area() function into the CVideo class.
* Renamed CVideo::getx() and gety() to get_width() and get_height()
* Made those two functions return the result of screen_area() instead of the other way around.
* Added preliminary support for high-DPI rendering to screen_area()
Note on the last point: When I fixed bug #1772 (aa8f6c7e7 right now but will probably change with rebasing)
I noted that SDL_GetWindowSize and SDL_GetRendererOutputSize returned the same results for me (even with
Window's automatic scaling for non-high-DPI-enabled apps disabled) but that the SDL documentation stated the
former returned screen coordinates and the latter pixels. In that same commit I changed the dimension functions
to use SDL_GetWindowSize. I've now reversed that decision and gone back to using SDL_GetRendererOutputSize so
I can guarantee output in pixels. If use_pixels is false, the code will return coordinates in 96 DPI, so I need
to have pixel measurements for the calculations.
Again, though, I do not know if SDL_GetWindowSize returns a different value that pixel size (which it's said
to do) on macOS or iOS. I'll need to do some testing. It's possible on those platforms I won't need the 96 DPI
measurements, but it's also possible it will be needed on on platforms, since all of our code relies on pixel
measurements.
