Yeah, I've seen this too (commented on it in a different bug).
The problem with the bitmaps is that they don't look that good in high resolutions, which is why SVG is available. The bitmap one is default though AFAIK.

Did you run previous GNOME versions on the same computer? If so - has the load time become worse?

Just as a tip: in gnome-games-extras there is a theme called Dondorf, which is partially SVG, loads in roughly half the time of Paris, and still looks rather sharp on good monitors.

I'll probably start looking at these performance complaints again soon... before this gets set as a duplicate, we will need more information about exactly which distribution you are running and such. Sometimes things just get messed up (often on a gdk level) when distros upgrade to the latest GNOME too quickly. 

Two comments:

On an historical level the Paris SVG set was included with known performance problems. It was hoped that recent improvements in librsvg - which we use to render the SVG - would fix things. It hasn't to any significant extent so we're actually going to have to address this issue.

I've did a preliminary profile of the code this afternoon to make sure what I thought was the problem really is the problem. Broadly speaking it is, but there is one thing that looks wrong. The code works by using gdk_pixbuf_loader. It actually uses it twice with a scalable image: the first time it theoretically loads just enough to determine if the image is scalable and then bails out. The second time it does the actual loading and rendering. In both cases we use gdk_pixbug_loader_close and in *both* cases this takes a long time. The second time around this is to be expected, we've told the loader that no more data is coming and its time to draw. However, the first time around we should only have given it enough data to determine the type of the file and so it shouldn't have anything to draw. This does not appear to be what is happening - all the data is being loaded both times. I suspect this is a change in the semantics of the librsvg pixbuf loader. 

So we may be able to get a factor of two out of the code by changing the way we do things. Something more than a factor of two would be desirable though.

The factor of two can indeed be easily obtained. The fix is in CVS right now - I'd like to push it out to the 2.14 branch, but I'll wait until I've tested it a bit more.

Now if I can just find another factor of 10 I'll be almost happy.

Will try to check out the new CVS code tomorrow if I have the time. A factor of two is in deed a great improvement!

You asked about distro's, here's my experience.
On a FC5 box, Dondorf loads in less than half the time of Paris. That computer is quite modern, but it still takes ~ 18 seconds for Paris. That's a lot.

On this computer, an Ubuntu Dapper, running GNOME 2.14, and XGL/Compiz/Glitz I get slightly different results: Paris: 14s, Bellot: 18s, Dondorf: 1s (!!!)
I presume it is something in the Glitz stuff that makes Dondorf go blazingly fast. But why can't the other themes use the same perks? Also note that this computer has just more than half the processing power of the one mentioned above, and still gets better results.


About delays during resizing of the window: is there a reason the rendering of the cards can't start only _after_ the resize of the window? Currently, as soon as you grab the corner, the CPU starts running. Can't it do that after you've released the corner instead?

eog (the image viewer) also takes a long time to load paris.svg, so I guess that 
it can only be improved in the library level.

Maybe in the meantime it would be best not to include paris.svg in the package, since the svg support can be considered to be broken.

(I'm running ubuntu dapper.)

Sergej: Your experience is about what is expected. Dondorf is a lot faster because the level of detail is a lot lower. All the images are included as bitmaps - which are fast and can afford to be blurry - while the text is SVG since it needs to be sharp, but the load time scales with the number of lines. Glitz can be used by Cairo (which is what librsvg uses now) and so should be able to speed things up at the hardware level (it still scales badly with the number of lines).

The resizing is slightly sub-optimal, but you can't simply wait until after the corner has been released - the application never gets that information, it only gets a series of resize events and so can't tell which is the last one (without waiting to see if another one appears). The current code is sub-optimal in that it doesn't work asynchronously and so it won't stop an old rescaling the moment the window resizes again. For Same-GNOME I used an asynchronous model which is moderately effective (albeit very ugly code). In this case the API we are using doesn't allow us to easily do anything asynchronously.

As for what we can do: as bla observes, rendering the entire theme image is slow at the library level. However, we can now (due to recent API improvements in librsvg) "cut up" SVG files into their component sections (based on tags in the file) and draw individual cards. It is quite likely that drawing 52 smaller cards is significantly faster than drawing the entire image. In any event, games like Klondike only show 8 actual images at the start so that is an instant factor of 5 (we render the rest as they appear, one at a time). It does not solve the problem for games like Freecell.

It is also possible we could trim down Paris to use fewer lines, although the style is fairly complex. (Factor of 2 perhaps?)

In summary, I think it is possible to get the extra speed we need to be decently quick. Paris is meant to push the limits, so I don't expect 100ms rendering times, but no one should be waiting more than a second or so at worst case (assuming modern hardware, etc.).

*** Bug 337532 has been marked as a duplicate of this bug. ***

The 2x speed-up code has been added to the 2.14 branch and should appear in the enxt stable release.

Getting this out of Unconfirmed state as it has long since been acknowledged and work done to improve speed.  

I noticed that in the CVS the default card set is now svg. I think that this is a bad idea since the svg rendering speed is still not reasonable (bonded.svg takes  about 5 seconds to load as opposed to less than a second for bonded.png).

Here's a possible solution to the blurry images problem: instead of providing bonded.svg and paris.svg, provide 2 png images which have 4x the current resolution of bonded.png (double the x and y resolution). Assuming that file size is proportional to resolution this will take less disk space than both svg files.

If the rendering speed is not improved by the end of the development cycle then that is what will happen.

I have a patch that implements the 'cut-up' rendering that comment 7 mentions. It's a nice speed improvement, e.g. on startup for klondike it goes from 2.5s to load the cards to ~0.5-0.7s (depending on which cards are shown first), using the Bellot cards.

The problem is that no card set except Bellot implements the needed IDs (.e.g "1_spade", "king_diamond" etc.) in the svg; so the card sets need to be fixed first. I tried to do that myself, but it's not as easy as adding a few IDs, since the other card sets are grouped not by card but in weird ways.

chpe:

Go ahead and attach it, and I can take a look at it. If it looks good, I'll most definitely update dondorf.svg, paris.svg, and my templates (rahga.com/svg) to use it. Beyond that, you'll have to talk to the maintainers.... One of the big reasons I stopped working on this is that I didn't see a nice way to set up the SVG cards without dumping the entire Inkscape community. I have no problem with that personally, but it's not something I could impose. :)

Created attachment 82578 [details] [review]
patch

This patch uses librsvg to load the SVG instead of gdk-pixbuf; and if you set the env var GAMES_CARDS_RENDER_SUB=1 then it uses subrendering for the cards.

Richard: 

On ragha.com/svg it says: "These cards for a good example of what can happen when you combine the powers of 'sed' with an SVG file." I assume this means that those SVGs were produced from SVG building blocks using some text transformation magic?
And also it says that you don't work on gnome-games anymore. Assuming I'm correct, and assuming you still have those tools, would you consider releasing them plus the origin input files, so someone else (or I, myself, should I find the time) could update the card sets? Thanks!

chpe:
There was a bunch of superflous junk and data in the SVG paths generated by the vector tracing program, IIRC. Stuff like "4.900 -0.423" where just "4.9-.423" would do. Way too much for one man to filter and fix by hand. I vaguely remember being amazed at what I was able to do with sed (console stream editor), but can't remember details any more. It's unlikey I have any of the scripts I used for it and other cards... I had a script that kinda-sorta rewrote paths so that the you could reposition certain exported SVGs so the center of it was "0,0" and every other point was relative, but it wasn't close to being reliable.

I may be able to look at this again in the next month or two, or maybe not. This is the only bug I'm even remotely interested in looking at anymore. :)

So the new games-card-images code in svn trunk has this fix. Now all that remains is to update the themes.

Created attachment 89255 [details] [review]
fix for "paris" theme

I have now converted all themes except "Ornamental".

All card themes have been converted.

Now for the question whether that's enough speed-up... while this helps for the case where few different cards are shown (e.g. in klondike, initially), this doesn't help for the case when many or all cards are shown (in freecell initially, or in a game that has progressed).

Re-assigning to new default owner.

Using AisleRiot 2.30.0, I clicked on the "View" menu and found no option to change the card theme. I check the other menus and no option appeared there either.
This renders this bug "unable to reproduce".

Closing this one. The only thing remaining would be to optimise librsvg, but that's not going to happen.

This bug is being reassigned to the "general" component so we can close the aisleriot bugzilla component.  Apologies for the mass email!