| | <<<Back 1 day (to 2012/05/12) | 2012/05/13 |
| sebras | Robin_Watts tor8: in draw/draw_glyph.c::fz_evict_glyph_cache() we call fz_hash_len() to determine how many keys are in the hash table and iterate over those keys. | 00:02.10 |
| Robin_Watts | mmm | 00:02.20 |
| sebras | but fz_hash_len() does not return the number of entries used in the hash table, it returns the number of allocated slots (used + unused). | 00:02.55 |
| Robin_Watts | sebras: Right. | 00:03.16 |
| | We run through every slot in the table, throwing away anything in there. | 00:03.29 |
| sebras | or am I missing somthing subtle... it is kind of late... ;) | 00:03.29 |
| Robin_Watts | The glyph cache eviction stuff is a bit crap; when the cache gets full we ditch everything. | 00:03.58 |
| | i.e. for every slot, throw away the contents of the slot. | 00:04.17 |
| | Does that make sense? | 00:04.31 |
| sebras | yes, I'm thinking about the validity of the key though. | 00:04.36 |
| | and the relation between size and load in the hashtable. | 00:04.57 |
| Robin_Watts | would you be happier with if (key && key->font) fz_drop_font() ? | 00:05.22 |
| sebras | I think that might be what's nagging me, yes. | 00:05.42 |
| Robin_Watts | I think I would too. | 00:05.59 |
| | How can this work? | 00:06.15 |
| | Maybe if it's only ever called when it's completely full? | 00:06.31 |
| sebras | because we always fill the hashtable to max? :) | 00:06.32 |
| Robin_Watts | We empty it whenever we destroy a context. | 00:07.03 |
| sebras | fz_evict_glyph_cache() can also be called when the glyphcache is dropped. | 00:07.11 |
| Robin_Watts | so I'm confused. | 00:07.14 |
| sebras | exactly. | 00:07.16 |
| Robin_Watts | Probably worth a step through with a debugger. | 00:07.37 |
| sebras | or is it the case that key->font is almost always NULL so used or unused alike have ->font == NULL? | 00:08.38 |
| | no... that doesn't make sense... | 00:09.43 |
| Robin_Watts | key being null would mean that key->font can't be read. | 00:10.05 |
| sebras | see. I'm tired. :) | 00:10.46 |
| Robin_Watts | And it's a saturday. sunday now even. | 00:11.08 |
| sebras | there are some intelligent neurons still lurking in there, but most seem to have dozed off... | 00:11.15 |
| | I stumbled upon a pdf that took ages for mupdfinfo to process. mostly because it has an insane amount of shading dicts which didn't fare well coupled with the O(n^2) algorithm in mupdfinfo... | 00:12.43 |
| | so I'm trying to transplant a hashtable into mupdfinfo, but maybe I should continue tomorrow. | 00:13.20 |
| Robin_Watts | Which bit is n^2 ? | 00:18.08 |
| | oh, gatherdimensions etc. | 00:19.07 |
| | A hashtable would work. | 00:19.31 |
| | Just not using linear extension on the arrays would help a lot I suspect. | 00:20.11 |
| sebras | Robin_Watts: most of the time seems to be spent in pdf_objcmp()... | 00:57.27 |
| | that's why I'm thinking hashtable. | 00:57.34 |
| | and then sorting the entries before printing. | 00:57.45 |
| | I guess that's why I used an array way back when. | 00:58.05 |
| egeriis | Hi there, I'm having an issue that you might be able to help with. I'm using GraphicsMagick for resampling and converting images into PNG. Now I'm having an issue where html2ps is not recognized when I'm trying to convert an HTML document to PNG. I'm using the convert helper program which gives me this error: No decode delegate for this image format | 13:11.28 |
| | Then when I try to run it through two steps; with html2ps directly to convert from HTML to PostScript and afterwards to PNG with convert. This fails as it seems convert it merging three pages into the same PNG document, although I'm setting a %d in my ouput filename | 13:13.36 |
| | Output: http://pastebin.com/MeA3HPmb | 13:15.02 |
| sebras | Robin_Watts: are you online? | 23:17.26 |
| | or at least awake. | 23:17.34 |
| Robin_Watts | I am | 23:19.09 |
| sebras | Robin_Watts: is there a requirement on the keys for the hash table to be packed? | 23:19.31 |
| Robin_Watts | I don't follow the question. | 23:20.45 |
| | When you create a hashtable, you specify the length of the keys. | 23:20.58 |
| | up to MAX_KEY_LEN bytes. (48) | 23:21.14 |
| sebras | yes, and if the key I'm using is a struct which has padding between the members... | 23:21.20 |
| | we're using the entire contents of the struct as input to the hashing-function. | 23:21.48 |
| Robin_Watts | Yes. | 23:21.55 |
| | If there is intra member padding then you'll need to zero that padding. | 23:22.10 |
| | (i.e. memset the key struct to zero, then set the values) | 23:22.27 |
| sebras | then I think I know why valgrind is giving me errors on the first lookup in an empty hashtable. | 23:22.55 |
| Robin_Watts | :) | 23:23.28 |
| sebras | finally. | 23:28.58 |
| | I wonder if we've cared about memsetting the key everywhere hash tables are used. | 23:29.15 |
| | seems like that is actually the case. | 23:33.50 |
| Robin_Watts | glad it's working. | 23:40.33 |
| | I'm off to bed now. | 23:40.39 |
| | night | 23:40.42 |
| sebras | night! | 23:40.50 |
| | Forward 1 day (to 2012/05/14)>>> | |
IRC Logs