I am a big fan of Graphics32 library.
The official Graphics32 is moved github:
https://github.com/graphics32and the documentation is
https://graphics32.github.io/Docs/_Body.htmI think the last state is ver 2.0 which is a rework specially in merging GR32 with VPR (Advanced Polygon things).
Another different with GR32 ver 1.9x (and below) is that in ver 1.9.x any calculation is suggested in integer (rather than floating point) which was far faster in that day;
While in ver 2.0 (svn-trunk/ git-master) the suggested calculation is in floating point (rather than TFixed) because the use of direct lowlevel x86/SSE/SSE2/SSE3 instruction which is now faster then.
I never try the GR32 version at CodeTypon/pilotlogic, but I assumed that (as usually) CodeTypon may modify some lines of code (plus bugfixes) any components/library they used for better "plug and play" softwares.
As for your question,
IMHO you can use GR32, the layers+sprites is very fast rendered especially when your layers are configured properly. That is because only few part of screen buffer repainted. Which the faature I didn't found in alternative library (a.f.a.i.k)
see MicroTiles for detail.
https://graphics32.github.io/Docs/Additional%20Topics/Repaint%20Optimization.htmAf for crossplatform,
for bitmap storage/buffer reason, GR32 depends on native VCL/win32-units for windows; otherwise it depends on widgetset (qt,gtk,customdrawn,cocoa/carbon).
I think it is because GR32 actually works best on 2 area: very fast buffer manipulation & very fast render on actual screen buffer by minimize the area being repainted.
So, again, your GR32 layers project will best depends of how you manage the layers properly.
For example, you know for each layer the "paint" procedure will be called twice, first for calculate the area being updated, and the second chance is for actual rendering.
I assumed you recognize it well yet.
--sorry for my bad/limited english if then--