On 05/19/2011 09:42 AM, Yaniv Kaul wrote:
On 05/19/2011 09:18 AM, Yonit Halperin wrote:
Hi,
you are not looking at the right cache. THe right cache is
red_client_shared_cache.h (shared among multiple monitors; doesn't
store images, only ids).
The cached you looked at is the cache of the canvas.
Cheers,
Yonit.
That still doesn't make any sense to me:
- I'm looking at some kind of cache (the relevant function names are
image_cache_put and image_cache_get). If it's not an image cache then
someone made a poor choice of names for them.
It is an image cache but it is used by the server for canvas rendering.
My guess is that it was more useful when images were compressed in the
driver (ages ago). This cache allowed fetching images that were rendered
in the server without the need to encode them over and over again. Since
images are no longer compressed in the driver, this cache is not
critical. It has still small advantage, since it already stores the
pixman_image object of the image and we don't need to recalculate it
(see canvas_get_image_internal in canvas_base.c) . But I think it
doesn't worth enlarging this cache and storing this pixman imagess.
And yes, the name choices are confusing...
About the X guest - need to be checked.
- Per the current code, the cache has a 1024 slots hash table, yet only
2 items max. can fit into it. If it is caching for the canvas, does it
really need to cache only two items, and if that's so, is that the right
way to do it?! (btw, enlarging the 2 items limit higher makes more items
go there right away, so perhaps there is some sense in having more
there? Donno).
- When using XP, I do see entries get into it, when using F15 I don't.
Not sure if canvas is something you'd see in X as well.
I'll take a look at red_client_shared_cache.h . Already spotted a typo
there.
Y.
On 05/18/2011 10:54 AM, Yaniv Kaul wrote:
I suspect the image caching in the server is not the greatest:
1. Using latest Fedora 15 and QXL driver, I don't see any image being
cached - at all.
2. Using XP with latest QXL driver, I do see some caching activity, but
I suspect:
- the cache is limited to 2(!) items only (as IMAGE_CACHE_MAX_ITEMS
is 2)
- even if we fix the above (so IMAGE_CACHE_MAX_ITEMS is
2*IMAGE_CACHE_HASH_SIZE for example) there will be, many times, slot
collisions. May or may not be such a big deal, depends how much we
really think we'll be caching.
- we are not caching that many images anyway. I expected with the above
change to have a lot more images cached. I suspect the driver does not
send many images for caching to the server for some reason.
All that I've done to gather the above is sprinkle some red_printf()'s
after reading the code:
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
