| | <<<Back 1 day (to 2012/03/11) | 2012/03/12 |
| kens | Robin_Watts : can you ping me when you come online please, not urgent. | 08:56.54 |
| Robin_Watts | kens: ping. | 09:22.08 |
| kens | Morning Robin | 09:22.19 |
| Robin_Watts | Morning. | 09:22.25 |
| kens | Was trying to use Memento on Saturday | 09:22.28 |
| | THe Ctrl-Alt-Q quickwatch doesn't set a breakpoitn that works for me. | 09:22.45 |
| | So I set a break manually | 09:22.53 |
| | give me one second | 09:22.59 |
| Robin_Watts | Ctrl-Alt-Q never sets a breakpoint. | 09:23.12 |
| | You need to set a breakpoint on Memento_breakpoint. | 09:23.25 |
| kens | Oh, then I misunderstood | 09:23.25 |
| | Ah.... | 09:23.30 |
| | I found setting a breakpoitn on globals_sequence == globals.breakAt worked OK, if I set the ignore count to be the same as the 'num'. | 09:24.14 |
| | Does that work too ? | 09:24.19 |
| | I ask because it semed to give unexpected results | 09:24.33 |
| Robin_Watts | kens: The code will call Memento_breakpoint in that case, yes. | 09:24.42 |
| kens | Which I haven't checked yet, but was going to | 09:24.42 |
| | Robin_Watts : so I'm manually doing the same thing :-) | 09:24.56 |
| | OK that's fine then, thanks | 09:25.12 |
| Robin_Watts | Memento_breakpoint will be called in cases other than the one your breakpoint would be called in too. | 09:25.20 |
| | (like corruption being detected etc) | 09:25.31 |
| kens | Hmmm, I guess right now I'm only interested in the memory allocation | 09:25.41 |
| Robin_Watts | (and just after a list of leaked blocks is printed out) | 09:26.05 |
| kens | THe oddness is that some allocations weren't being done in the pdfwrite code, but in the PCL interpreter | 09:26.07 |
| | SO I need to check if the PCL interpreter leaks too. | 09:26.24 |
| | When not going to pdfwrite | 09:26.34 |
| Robin_Watts | Could be. | 09:26.41 |
| | Or it could be things that the PCL interpreter allocates and then passes to pdfwrite? | 09:26.58 |
| kens | Well its possible pdfwrite is preventing a free as well | 09:27.00 |
| | In the case I recall it was a path | 09:27.12 |
| | Which pdfwrite should copy I think. | 09:27.20 |
| | well, enumerate actually | 09:27.31 |
| Robin_Watts | copy by refcount? | 09:27.36 |
| kens | Bad terminology, it should walk the path emitting appropriate move/line/curve/close commands into a recording buffer | 09:28.09 |
| | So the path 'shouldn't be touched at all in terms of ref countrs or anything | 09:28.31 |
| | But there could be a bug of course :-) | 09:28.40 |
| | Anyway, you've answered my real question, thanks | 09:28.58 |
| Robin_Watts | np. | 09:29.25 |
| kens | Morning Paul | 09:32.34 |
| paulgardiner | Hi kens | 09:32.44 |
| Robin_Watts | Morning | 09:42.02 |
| paulgardiner | Hi Robin | 09:50.03 |
| Robin_Watts | tries to remember what I was doing last week... I have a horrible feeling I'm going to regret it when I remember. | 10:59.11 |
| cipri | hi. any mupdf devs online? :-) | 11:30.21 |
| sebras | cipri: one and a half... | 11:32.59 |
| | cipri: what do you want to know? | 11:33.43 |
| cipri | :-) I would like to ask if you consider changing your makefile, so that also shared libs are created and not just static ones. | 11:34.28 |
| Robin_Watts | cipri: Submit a patch, and we'll consider it. | 11:34.52 |
| cipri | Robin_Watts: and one more quesiton. When do you think the next version will be released (somebody told me that "soon", but didnt now more exactly) | 11:37.00 |
| sebras | cipri: what app are you developing? | 11:37.10 |
| cipri | http://haikuware.com/directory/view-details/productivity/utilities/documentviewer-v024-dev | 11:37.26 |
| sebras | cipri: the intent is to have it out by the end of march. | 11:37.31 |
| | cipri: ah, haiku! I didn't recognize your alias. | 11:38.45 |
| cipri | :-) | 11:39.03 |
| | i think mupdf will be integrated into haiku at a later point, that's why i asked about shared libs | 11:41.22 |
| | it seems that mupdf on haiku pretty well. It feels smoother and faster than sumpatrapdf and mupdf on windows. | 11:46.32 |
| sebras | cipri: I'm happy to hear that. :) | 11:46.47 |
| cipri | thank you for the answer. bye :-) | 11:56.19 |
| Robin_Watts | cipri: before you go... | 11:56.31 |
| cipri | yes? | 11:56.37 |
| Robin_Watts | If you want any shared lib makefile changes in, it would be really good to get them to us within the next day or so. | 11:56.55 |
| | The ultimate arbiter for such things is tor, and he's not here, but we're trying to finalise stuff asap. | 11:57.26 |
| cipri | i was asking in fact myself, why you dont build your mupdf viewer on shared libs, why static? is there a certain reason? | 12:00.09 |
| | ok, i try to take a look at the makefile, and if i have a patch, i come back :-) | 12:03.34 |
| | bye, and have a good day :-) | 12:04.13 |
| Robin_Watts | I suspect, simplicity and portability. | 12:04.18 |
| | We want our makefile to work on every platform possible, and (I suspect) that shared libs are less portable than static ones. | 12:04.49 |
| | Too slow. | 12:04.55 |
| sebras | Robin_Watts: no, the motivation has more to do with versioning and compatibility I believe. | 12:15.49 |
| | or the lack there of.. | 12:16.05 |
| Robin_Watts | Well, we can introduce an api level component into the shared lib name. | 12:16.47 |
| | mupdf-1_0.1_0.so | 12:17.15 |
| | Morning tor8: see logs. | 12:27.15 |
| tor8 | morning Robin_Watts | 12:27.31 |
| | in principle I'm opposed to shared libraries, but everyone and his mother seems to be asking for one | 12:27.52 |
| | with the 1.0 api being stabilized, and the separation between public/private interfaces I'm less worried (but still worried) about the ABI stability | 12:28.23 |
| | the whole "shared libraries let you upgrade all your binaries at once by upgrading the library" idea has been proven false on so many occasions... but I shan't rant about it anymore today | 12:29.26 |
| | cipri: makefile portability and maintenance is another big reason, every platform has their own unique snowflake way of building shared libraries | 12:31.00 |
| Robin_Watts | I share your disquiet. | 12:31.02 |
| tor8 | ah, missed him it seems | 12:31.32 |
| paulgardiner | morning tor8 | 12:32.23 |
| tor8 | Robin_Watts: if we do go with shared libraries, I want a version sanity check (followed by abort) so that the version of the headers used to compile the binary match the version of the linked against library | 12:32.43 |
| | preferably in fz_new_context | 12:32.58 |
| Robin_Watts | tor8: Seems fair. | 12:33.01 |
| | And that seems the perfect place for it. | 12:33.08 |
| tor8 | hi paul | 12:33.20 |
| Robin_Watts | tor8, sebras: Did either of you work on header-split over the weekend? | 12:39.37 |
| | fz_convert_pixmap has the args the wrong way round IMHO. | 12:41.18 |
| | C's convention is (dst, src) | 12:41.32 |
| tor8 | Robin_Watts: that's an oversight, we should be following c's convention | 12:51.46 |
| Robin_Watts | Shall I change the code ? | 12:51.58 |
| tor8 | but oh boy that'll cause grief if you catch people using it unaware :) | 12:52.08 |
| | please do | 12:52.10 |
| Robin_Watts | will do. | 12:52.14 |
| | The text device... | 12:55.18 |
| | We have a to make an fz_text_span to pass to the device... and that 'updates' it to maybe be a list of them ? | 12:55.44 |
| tor8 | Robin_Watts: finished the new one friday, just need to rebase and push to master | 12:56.12 |
| Robin_Watts | Ah. I won't scribble docs for that then. | 12:56.28 |
| tor8 | the new one has a 'text page' and 'text (style) sheet' that are passed to the device | 12:56.44 |
| | the text page is a list of blocks, which is a list of lines, which is a list of spans, which is a list of chars with a given style from the style sheet | 12:57.14 |
| Robin_Watts | OK. | 12:57.30 |
| | That sounds nicer. | 12:57.35 |
| tor8 | I still need to update the iOS and android code to use it | 12:58.27 |
| | oh, and I see sebras has a couple of bugfixes in his repo we should merge in | 12:58.58 |
| Robin_Watts | I've just pushed my latest header-split | 13:03.30 |
| | tor8: Do you want me to handle taking on sebras stuff? | 13:09.13 |
| | (not much to handle :) ) | 13:09.23 |
| tor8 | yeah. I think we can switch to the header-split branch soon as well | 13:10.26 |
| | I wonder if it's easier to rebase sebras fixes or the header-split branch | 13:10.57 |
| Robin_Watts | I think they are all independent. | 13:11.18 |
| | Let me take on sebras stuff. | 13:11.33 |
| | Then I'll merge master to header-split | 13:11.43 |
| | Yeah, the merge went through automatically. | 13:17.17 |
| | Ah, but sebras' stuff has problems under MSVC... | 13:18.19 |
| sebras | Robin_Watts: feel free to pick up my patches. | 13:18.19 |
| | Robin_Watts: I believe that they are trivial they've just lingered in on my branch for some time. | 13:18.39 |
| | and no, I didn not have a look at your updated split-header branch. | 13:19.06 |
| Robin_Watts | sebras: The main thing is that you haven't worked on it - I was worried about merge headaches. | 13:19.37 |
| sebras | ah, no. | 13:19.45 |
| | I only rebase towards origin/master if others want my patches they need to rebase themselves. :) | 13:20.36 |
| Robin_Watts | Stupid MSVC has problems with isnan | 13:25.53 |
| | but a bit if #ifdeffery has solved that. | 13:26.04 |
| sebras | Robin_Watts: oh? how come? | 13:26.19 |
| Robin_Watts | #ifdef _MSC_VER | 13:26.34 |
| | #define isnan(x) _isnan(x) | 13:26.36 |
| | #endif | 13:26.37 |
| | isnan is C99. | 13:26.39 |
| sebras | oh. | 13:26.41 |
| | stupid indeed. | 13:27.01 |
| Robin_Watts | tor8, sebras: I'm going to grab some lunch. | 13:37.08 |
| | I've pushed sebras patches onto master and merged into header-split. | 13:37.31 |
| | The results of all that are in my repo on casper. | 13:37.44 |
| | Speak before I get back from lunch or I'll push it to the main repo :) | 13:37.58 |
| | chrisl: Nice idea about PSEUDO_RASTERISATION | 14:12.00 |
| | do you want to mail them about it? | 14:12.06 |
| chrisl | Robin_Watts: thanks (and for copying to tech, I *really* thought I had!). I was kind of hoping you'd try it with the problem file(s) you'd been fighting with before passing into them - do you have a way of getting timings from the sim? | 14:14.11 |
| Robin_Watts | Not trivially. And they wouldn't match the embedded thing anyway. | 14:15.00 |
| | Certainly any timings I got out would be no more definitive than the ones you have. | 14:15.41 |
| chrisl | Okay, let me make the changes in their code base, and double check it doesn't cause havoc in there - I *would* like to hear from Ray on the subject, though....... | 14:16.00 |
| Robin_Watts | When you mail them, I'd be at pains to say that while we believe it's safe etc, they should be careful to thoroughly test it and that the burden of QA falls on them. | 14:17.45 |
| chrisl | Sure, yeh. Do we cluster test @ 600dpi? | 14:18.39 |
| Robin_Watts | We do. | 14:19.13 |
| | but with this new fangled freetype thing, it shouldn't matter. | 14:19.29 |
| | (AIUI, PR is only applied during chars, not during line art) | 14:19.50 |
| | or do we? Maybe we top out at 300dpi. | 14:20.13 |
| chrisl | Yes. I thinking I could disable FT, and do two pushes one normal and one with PSEUDO_RASTERISATION disabled....... | 14:21.00 |
| | Oh, maybe we only do PCL @ 600? | 14:21.45 |
| | I suppose even with only PCL, it would still be a valid test....... | 14:22.39 |
| tor8 | Robin_Watts: fz_render_ft_glyph checks the aa level | 14:28.46 |
| Robin_Watts | Does it? Damn. I checked that. | 14:29.07 |
| | (Well, I grepped for places accessing ->aa | 14:29.19 |
| | ) | 14:29.22 |
| | Then I'm confused as to why it doesn't work. | 14:34.03 |
| | Oh, it only checks 0 or not. | 14:34.46 |
| | tor8: OK, we have a decision to make then. | 14:41.46 |
| | Either we need to update the glyphcache to store what level of AA was used to render a glyph with that glyph... or we need to have separate glyph caches per thread. | 14:42.28 |
| | or we need to make the AA context truly global. | 14:42.43 |
| | At the moment, the level of AA is not checked before we check the glyph cache - so we could match a previous rendering of a glyph that was done at a different AA level than we want. | 14:44.12 |
| | I really don't think we should have separate glyphcaches per thread. | 14:45.48 |
| | So I'm leaning towards either having a global AA setting, or updating the cached information with the AA level. | 14:46.32 |
| | fz_convert_color appears to have it's args the wrong way around too. | 14:47.30 |
| tor8 | Robin_Watts: we could make a context recreate its glyph cache when the aa level changes? | 14:57.25 |
| Robin_Watts | That would work as long as people set the required aa level, then clone the contexts for multi-band rendering. | 14:58.36 |
| | but if they clone, then set, the bands would end up using different glyphcaches. | 14:59.07 |
| | which would be bad. | 14:59.10 |
| | And if they recreate, we end up with 2 (potentially large) glyphcaches kicking about. | 14:59.30 |
| | I'm much more tempted to just add the aa level to the glyph record in the glyphcache. | 14:59.55 |
| | I'll have a go at that in a mo. | 15:00.17 |
| tor8 | or set the aa level in the glyph cache, and if it changes there just evict the lot? | 15:00.23 |
| Robin_Watts | tor8: I share the glyphcahe between contexts. | 15:00.44 |
| tor8 | hopefully nobody will render both aa and non-aa at the same time in different contexts? | 15:01.09 |
| Robin_Watts | thumbnail/non-thumbnail? | 15:01.19 |
| | printing/screen ? | 15:01.25 |
| tor8 | hmm, okay then | 15:02.12 |
| Robin_Watts | What are your thoughts on fz_convert_color ? | 15:04.20 |
| henrys | Robin_Watts, chrisl:I didn't understand the performance email - these performance problems being reported use non resident fonts and not the ufst? | 15:13.23 |
| Robin_Watts | henrys: These are the mails from Customer 532 regarding WWTTM1CT | 15:13.58 |
| | They are using AFS internally. | 15:14.16 |
| chrisl | henrys: my understanding is that the jobs in question have embedded fonts, which still use the AFS code. | 15:15.23 |
| henrys | oh okay I didn't know that. | 15:16.01 |
| | chrisl:great catch. | 15:16.34 |
| | I think it's a really good idea to suggest. | 15:16.46 |
| chrisl | I was surprised at the difference on my (totally non-real world) test job, to be honest | 15:17.21 |
| | Robin_Watts, henrys: if you've any interest in seeing the effect, I've just bmpcmp'ed the difference between with PSEUDO_RASTERISATION and without @ 600dpi........ | 15:20.11 |
| Robin_Watts | http://www.theverge.com/2012/3/12/2863553/a-bit-of-heat <- So, forgetting stuff warms my head? | 15:22.31 |
| chrisl | Robin_Watts: how will you know if you can't remember how cold your head was to start with? | 15:24.08 |
| tor8 | Robin_Watts: dst, src as usual (re convert color) | 15:24.16 |
| Robin_Watts | tor8: Cool. Have made that change too. | 15:24.30 |
| | http://ghostscript.com/~regression/chrisl/compare40.html Number 251 Page 2. | 15:25.48 |
| | The image of the satellite. | 15:25.59 |
| | That's the worst one I've spotted. | 15:26.30 |
| | and the houses in the following one. | 15:26.51 |
| | but, TBH, those are stupid fonts. | 15:27.02 |
| henrys | what's bugging the crap out of me is I thought I did this already for pcl at high res. Now I see what I did if (gs_currentdevice(pxli->pgs)->HWResolution[0] >= 300) gs_setgridfittt(pxs->font_dir, 0); | 15:30.16 |
| | | 15:30.16 |
| chrisl | Robin_Watts: that (the satellite) is the biggest difference I've seen as well - but I'm actually thinking with PR is better......... | 15:30.18 |
| Robin_Watts | I'd expect with to be better. | 15:30.48 |
| | just not by much. | 15:30.54 |
| chrisl | Doh, I meant without PR | 15:31.00 |
| Robin_Watts | The bmpcmp is candidate, reference, diff. | 15:31.39 |
| | presumably candidate = no PR ? | 15:31.47 |
| chrisl | Yeh, the satellite and house, I prefer the candidate rendering | 15:32.04 |
| Robin_Watts | really? | 15:32.16 |
| | with the house, you lose lines on the chimney. | 15:32.24 |
| | (Make sure your mouse pointer is not in the image :) ) | 15:33.12 |
| chrisl | I know, it just looks more "right" to me | 15:33.53 |
| | On the reference, the lines look too heavy to me | 15:34.26 |
| henrys | chrisl:so when we run this in the latest code we get ft rendering right? | 15:35.28 |
| | our code that is. | 15:35.34 |
| chrisl | henrys: no, these are all PCL files | 15:35.42 |
| henrys | I mean the customer's test. | 15:35.57 |
| | with cid fonts. | 15:36.05 |
| chrisl | I don't think the customer's tests are using CID fonts, are they? | 15:36.27 |
| | Robin_Watts: ^^ | 15:36.38 |
| henrys | or embedded fonts. | 15:36.40 |
| Robin_Watts | embedded fonts. | 15:37.04 |
| | In 9.0x, we'll be using freetype in the case that the customer is complaining about. | 15:37.29 |
| chrisl | Yes, with embedded fonts we'll almost always use Freetype (there is a bug that causes a *few* CID font to still use the AFS code......) | 15:37.40 |
| Robin_Watts | hence chrisl is 'faking' the test by looking at PCL files. | 15:37.56 |
| henrys | so another case for upgrade which they should be reminded of. | 15:38.19 |
| | Robin_Watts:right got it. | 15:38.59 |
| chrisl | henrys: Given that we found FT and AFS performance to be quite similar, I doubt that's going to be a big convincer....... | 15:39.28 |
| Robin_Watts | In their '2 bit' mode, they'd get AA for free with freetype, right ? | 15:40.24 |
| chrisl | No | 15:40.38 |
| | Robin_Watts: a clear regression http://ghostscript.com/~regression/chrisl/compare46.html seventh row down | 15:40.48 |
| kens | There's an open enhancement for tha | 15:40.50 |
| Robin_Watts | Oh, no, cos gs still doesn't call freetype in AA mode. | 15:41.01 |
| henrys | chrisl:so you are saying if they fix this then upgrade we'll have a performance regression with this same test file? | 15:41.10 |
| chrisl | henrys: possibly, I don't know, I'd have to check it | 15:41.34 |
| | Robin_Watts: gs currently has no way to handle a glyph pixmap | 15:42.14 |
| Robin_Watts | doesn't see how you get to performance regression from here. | 15:42.19 |
| | chrisl: That looks like a genuine regression, yes. (Functionality, not performance) | 15:42.50 |
| henrys | that's a pcl->pdf test why is it rasterizing at all. | 15:44.11 |
| | ? | 15:44.12 |
| chrisl | How would you check the conversion without rendering it? | 15:44.52 |
| Robin_Watts | henrys: The cluster and bmpcmp both pcl -> pdf then rasterise the produced pdf to test it. | 15:45.14 |
| henrys | Robin_Watts:ah of course. | 15:45.23 |
| chrisl | It saves lots of false positives when the *structure* of the PDF output changes....... | 15:45.52 |
| henrys | Robin_Watts:if AFS == FT now chrisl speeds up WWTTM1CT by turning off PSEUDO then AFS is faster the FT so upon upgrade to FT the customer will test this file and report a regression. Was that your question? | 15:48.40 |
| Robin_Watts | I follow. | 15:48.56 |
| chrisl | Robin_Watts: the problem file from cust 532, where can I get it? | 15:49.11 |
| Robin_Watts | I believe chrisl's assertion that 'FT == AFS' is true in general, rather than being true in this particular case. | 15:49.44 |
| | So given that we haven't had massive lists of people complaining about FT being slower since 9.0, we probably don't have to worry in general. | 15:50.30 |
| | chrisl: It's on their ftp site. | 15:50.42 |
| | Or I can get it to you. Hold on a tick... | 15:50.52 |
| chrisl | If you don't mind - I seem to get into fights with their ftp site, for some reason | 15:51.27 |
| Robin_Watts | OK. In my home dir on casper, there are 2 WWTT files. Those are the 2 in question. | 15:52.17 |
| chrisl | Got them, cheers. | 15:52.55 |
| Robin_Watts | no problem. | 15:53.16 |
| chrisl | Hmm, interesting, using -dNOCACHE, 600dpi, using Freetype renders WWTTM1CT.pdf in 30.9 seconds, whilst the AFS (with PSEUDO_RASTERISATION) takes 47.5 seconds | 15:56.42 |
| Robin_Watts | and without PR ? | 15:57.03 |
| chrisl | Need to rebuild - this is a debug build, btw | 15:57.17 |
| | Without PR, the AFS code does it in 27.4 seconds | 15:58.23 |
| Robin_Watts | 27.4 is close enough to 30.9 that we don't need to worry. | 16:03.19 |
| kens | tI think so too | 16:03.25 |
| henrys | great news. | 16:03.45 |
| chrisl | With the cache enabled, I can't get a meaningful difference between the AFS code w/o PR, and the Freetype code - there's more noise than speed difference | 16:03.46 |
| ray_laptop | morning, all | 16:05.04 |
| henrys | hi ray_laptop | 16:05.21 |
| chrisl | good morning ray_laptop | 16:05.28 |
| ray_laptop | chrisl: I saw your email and replied to you (and Robin_Watts). Unfortunately I already thought of that, so that is already in force | 16:05.35 |
| chrisl | Oh, oh well :-( | 16:06.11 |
| ray_laptop | unless you see something in the latest profiles that shows the fill_adjust -1 code is still happening | 16:06.16 |
| | I've mostly been focused on the Alphard issue | 16:06.45 |
| chrisl | It seem to still be in force for type 42 fonts. | 16:06.54 |
| ray_laptop | chrisl: Oh, really -- which module is that (I'll check the source I have from them) | 16:07.42 |
| chrisl | But these are type 1 fonts :-( | 16:07.42 |
| | ray_laptop: psi/zchar42.c | 16:07.53 |
| henrys | ray_laptop:this does raise a more general issue, is there a class of files that perform poorly on the target vs. say files that have good performance relative to 5th gen? | 16:08.10 |
| ray_laptop | chrisl: thanks. My change was in gxtype1.c | 16:10.21 |
| henrys | chrisl:I'd be tempted to turn that off for pcl but I guess the switch over to freetype will be soon enough, well if 532 ever leaves you alone. | 16:10.29 |
| chrisl | henrys: yes, *if*..... | 16:10.53 |
| Robin_Watts | tor8, sebras: I've finished running through fitz.h, moving stuff into fitz-internal.h as much as I can, documenting functions/types etc. | 16:11.52 |
| ray_laptop | henrys: the only file they've told us need improvment relative to 5th gen are these WWTT files -- and only at 1200 dpi. All text | 16:11.56 |
| Robin_Watts | I've hidden (most of) fz_buffer. | 16:12.07 |
| | Still remaining to do = links/link_dests and text stuff. | 16:12.49 |
| ray_laptop | henrys: it's been confusing because they send us test timings on a 750MHz engine, but then turn around and say it is too slow when they use a 500MHz engine | 16:12.53 |
| Robin_Watts | And they change the versions of the files whenever they feel like it. | 16:13.26 |
| | And their profiler shows the wrong function names in some cases. | 16:13.39 |
| | And spuriously adds 2 seconds to random functions. | 16:13.49 |
| | But other than that, they are absolutely spot on. | 16:14.01 |
| ray_laptop | Robin_Watts: oh, you mean between the "original" and a 6 page or 10 page subset (the original has 50 pages) | 16:14.06 |
| Robin_Watts | ray_laptop: Yes. | 16:14.13 |
| henrys | it's interesting the text stuff because that isn't where we usually fall down. I would expect to see the usual complaints about images. I hope these aren't the only performance tests they are using. | 16:14.21 |
| ray_laptop | Robin_Watts: I also see sporadic "delays" on the Alphard target -- that's what I pushed back to Eric about last night | 16:15.01 |
| henrys | paulgardiner:would a meeting tomorrow be reasonable or do you need more time? | 16:16.17 |
| | I was thinking after the tech meeting 9:30 PDT? | 16:16.53 |
| Robin_Watts | I think Tuesday nights are bad for paulgardiner | 16:17.10 |
| chrisl | ray_laptop, Robin_Watts: there is also some *hideous* code in base/gxhintn1.c which saves me about 1 second running uncached when I disable it - not much, but..... | 16:18.12 |
| ray_laptop | a simple diagonal stroke page (repeated 20 times) varied from .012 seconds up to 1.2 seconds, and the time to output the page ranged from 0.16 seconds to over 3 seconds-- I'm inclined to think that everything over the shortest time is their fault | 16:18.52 |
| paulgardiner | henrys,Robin_Watts: Tuesday's aren't ideal if the meeting was likely to go past 1/2 hour, but otherwise fine. | 16:19.28 |
| henrys | paulgardiner:wednesday is fine too. | 16:19.46 |
| | I'm around each morning (your late afternoon/early evening) and it makes no difference to me. | 16:20.38 |
| chrisl | ray_laptop: would it be worth (or have you already) suggesting they make the GS task a higher priority? | 16:20.40 |
| ray_laptop | so using the minimum times, gs _should_ be able process the 20 pages in < 6 seconds instead of the 30 they see | 16:20.58 |
| Robin_Watts | I worry that they have some weird driver for their hardware device that's soaking up interrupts in the background. | 16:21.22 |
| | (Like a PIO data transfer task or something) | 16:21.31 |
| | and so when that goes off, we lose 2 seconds before we carry on. | 16:22.13 |
| ray_laptop | chrisl: generally task priority is given to driving the engine (which is mostly things like starting DMA and is short), but given some of the code I've seen, I wouldn't be surprised if some "task" is polling in a wait loop rather than using a semaphore and task blocking | 16:22.36 |
| | that's why I insisted on them collecting the CPU time for the gs task. Of course if the culprit doing the wait loop is one of the functions they have us call ... | 16:24.21 |
| paulgardiner | Oh ok... probably Wed would be better most weeks, but could we make it Tues this week? Would be good to get other's input early in the week. | 16:24.23 |
| henrys | paulgardiner:okay we'll start at 9:30 promptly. | 16:24.57 |
| | tuesday. | 16:25.01 |
| ray_laptop | 9:30 which TZ ? | 16:25.08 |
| Robin_Watts | (That's 5:30pm UK time) | 16:25.17 |
| ray_laptop | Robin_Watts: OK. | 16:25.25 |
| henrys | PDT see above. | 16:25.25 |
| paulgardiner | henrys: ok great | 16:25.27 |
| chrisl | ray_laptop: I'd expect the process driving the engine to be given "real time" priority, but there might still be some room to increase our priority and reduce the occasions when other "normal" processes can interrupt us. | 16:25.47 |
| ray_laptop | chrisl: it's hard to imagine that they have that much other processing to do. | 16:26.18 |
| Robin_Watts | 'normal' processes interrupting us wouldn't take 2 second chunks. | 16:27.14 |
| | I can't believe they are just using the realtime clock - so it's either going to be a profiler bug (seems like an odd one) or there must be something taking time at a higher priority level (like an interrupt). | 16:28.01 |
| ray_laptop | from what I've been led to believe their ASIC does the rendering using their graphics orders, color correction, and halftoning | 16:28.08 |
| | Robin_Watts: the PPA times I have don't use the profiler. It's just calls to collect the high resolution clock time and store it in a buffer that gets dumped occassionally | 16:29.16 |
| Robin_Watts | It's the kind of stupid thing where they might be getting an interrupt to tell them to pass data to the ASIC, setting up a DMA to do the transfer, and then polling stupidly until the the DMA completes. | 16:29.30 |
| | ray_laptop: Right, but in the profiles I'm seeing, I'm seeing these 2 second lumps too. | 16:29.47 |
| chrisl | So, it sounds to me like the ball *should* be back in their court........ | 16:30.34 |
| ray_laptop | well, it's definitely in their court to collect the task CPU time | 16:31.20 |
| | does windows collect the CPU time for a thread somehow ? | 16:32.10 |
| Robin_Watts | ray_laptop: Yes. | 16:32.26 |
| | GetThreadTimes is the magic function on windows, I think. | 16:32.37 |
| | I've done profiling based on that before. | 16:33.14 |
| ray_laptop | ahh, I found http://stackoverflow.com/questions/1393006/how-to-get-the-cpu-usage-per-thread-on-windows-win32 | 16:33.35 |
| henrys | Maybe reaching but It would be interesting to see if the profile anomalies show up in a profile of their PCL interpreter. | 16:35.01 |
| ray_laptop | I'm going to collect that for the simulator for the 'simple' pages and for the andy*** file and see what the percentages are | 16:35.42 |
| henrys | bbiaw | 16:36.17 |
| ray_laptop | chrisl: thanks for pointing out that zchar42 for fill_adjust = -1. I had grepped the base/* but missed the psi directory | 16:42.00 |
| chrisl | ray_laptop: np - shame it doesn't help for the (current) problem files......... | 16:43.45 |
| ray_laptop | chrisl: right. | 16:44.04 |
| | on the 'andy' test file (Alphard problem) the debug build is about half the speed of the release build (600 dpi clist bandheight=128 pgmraw going to /dev/null) | 16:56.46 |
| Robin_Watts | tor8: You here? | 17:14.06 |
| tor8 | Robin_Watts: yes. | 17:14.17 |
| Robin_Watts | Shall I push header-split to master? Or do you want to check it first? | 17:14.43 |
| | It passes sane. (Don't know if I said that earlier) | 17:15.20 |
| tor8 | push to master, I've given it an overview | 17:15.52 |
| Robin_Watts | I've added the AA level to the glyphcache key. | 17:16.01 |
| tor8 | I have the text branch rebased on top of it | 17:16.03 |
| ray_laptop | header split -- sounds like a migraine | 17:16.09 |
| Robin_Watts | And I've just added -w and -h (and -f) to mudraw. | 17:16.18 |
| tor8 | and I'm working on a renaming cleanup pass, that I'd like some input on | 17:16.28 |
| Robin_Watts | ok. | 17:16.36 |
| tor8 | http://ghostscript.com/~tor/stuff/renames.txt | 17:17.01 |
| | basically try to sort out our use of accessors and usage of the words get, lookup, find | 17:17.42 |
| ray_laptop | my system is running WAY S...L...O...W -- going away for a reboot to see if that helps. | 17:20.07 |
| Robin_Watts | save->write, debug->print, cool. | 17:20.13 |
| | Removing 'get', ok. It means we'll no longer match set/get in those cases, but that's OK if we are consistent elsewhere. | 17:20.44 |
| tor8 | I think the postscript convention is useful there (see "currentmatrix" vs "setcurrentmatrix" and friends) | 17:21.13 |
| | the other option is adding in "get" everywhere to turn the functions into complete verb-noun phrases, but that's a lot of extra words everywhere | 17:21.49 |
| Robin_Watts | OK, so the first question... pdf_lookup_{v,h}tmx | 17:21.51 |
| | why lookup there? | 17:22.02 |
| tor8 | that's sort of what I wanted your input on. | 17:22.19 |
| Robin_Watts | does that bump a refcount on the thing we find or something? | 17:22.21 |
| | I think saying things like fz_bitmap_width makes perfect sense. | 17:22.43 |
| tor8 | we have pdf_lookup_cmap to look up stuff in encodings | 17:22.44 |
| | pdf_lookup_hmtx looks up the horizontal metrics for a glyph in the metric table | 17:23.15 |
| Robin_Watts | but if we ever look something up, and the act of looking something up takes a reference to something, we should have a verb there. | 17:23.26 |
| | because fz_bitmap_width means "the width OF the bitmap" | 17:23.40 |
| tor8 | lookup is the verb...? | 17:23.55 |
| Robin_Watts | Yes, I'm not disagreeing with anything I've seen so far. | 17:24.15 |
| tor8 | pdf_lookup_font_hmtx? | 17:24.22 |
| | oh. I see that fz_hash_table follows your preferred naming order :) must've been the old code I originally took the implementation from | 17:25.23 |
| | do we want to use find or lookup for when we are looking for things in containers? | 17:26.12 |
| | hash tables, the store, glyph cache, etc | 17:26.21 |
| Robin_Watts | lookup implies we lookup something and get the things reference to it. | 17:26.46 |
| | find implies we lookup something and get our own reference to it. | 17:26.58 |
| | Maybe that's somewhat hopeful on my part :) | 17:27.09 |
| tor8 | I doubt there's any real distinction to it now | 17:27.23 |
| Robin_Watts | I'm saying we could pick verbs such that there would be such a distinction. | 17:27.44 |
| tor8 | yes. unless we decide to make them all use the same verb and behave the same with regards to references | 17:28.10 |
| Robin_Watts | when we find things in the glyphcache/store, the act of finding takes a reference. | 17:28.12 |
| | Well, the htmx things aren't refcounted objects. | 17:28.39 |
| tor8 | for sanity's sake I have a list of standard words that imply taking ownership of a reference: new, load, and keep so far. | 17:29.01 |
| Robin_Watts | yes. | 17:29.19 |
| | I'd like us to elect a verb to mean the same for a lookup/find operation. | 17:29.36 |
| tor8 | if we want a similar word for looking up and taking a reference in one call (such as getting from the store) then we could, yeah, what you said :) | 17:29.45 |
| | take? | 17:30.12 |
| | a bit too similar to keep that | 17:30.20 |
| Robin_Watts | To me, find implies that at the end of the operation, I *have* something. | 17:30.31 |
| tor8 | right. makes sense. | 17:30.43 |
| Robin_Watts | and lookup implies that my finger is pointing to something in a table. | 17:30.46 |
| | So I'd vote for find/lookup. | 17:31.06 |
| tor8 | okay, so lets reserve find for lookups that give you the reference | 17:31.09 |
| kens | heading off, night all | 17:31.10 |
| tor8 | and lookup for the others | 17:31.12 |
| Robin_Watts | cool. | 17:31.18 |
| tor8 | be they reference counted or borrowed references | 17:31.20 |
| Robin_Watts | yes. | 17:31.26 |
| tor8 | be they *not* reference counted that is | 17:31.30 |
| Robin_Watts | yeah. | 17:31.38 |
| tor8 | so looking up values in something should use lookup | 17:31.46 |
| Robin_Watts | Yes. I think it means your current list is spot on. | 17:32.01 |
| tor8 | and peeking at hands off things as well | 17:32.05 |
| | pdf_find_page_number would become lookup then | 17:32.25 |
| | as would fz_find_blendmode | 17:32.52 |
| | correct? | 17:32.55 |
| | but find_device_colorspace would remain | 17:33.12 |
| Robin_Watts | Yes. | 17:33.42 |
| | Although the difference for things that return ints is moot :) | 17:34.12 |
| tor8 | still, I'd like to make it crystal clear that "finders" always take a reference | 17:35.03 |
| Robin_Watts | Hard for me to argue against clarity :) | 17:35.21 |
| tor8 | so, pdf_find_builtin_font I guess should become lookup too, or do you have any other suggestions? | 17:35.43 |
| Robin_Watts | Does finding a builtin font not get you a reference ? | 17:36.09 |
| | oh, no, it points to a static buffer. | 17:36.47 |
| | so lookup, yes. | 17:36.53 |
| | I'm gonna have to run to pickup Helen in a mo. | 17:37.19 |
| tor8 | and I'm heading for dinner | 17:37.26 |
| Robin_Watts | Well, I've unleashed header-split on the world. | 17:38.30 |
| tor8 | um, origin/master doesn't compile | 17:39.24 |
| | conflicting types for fz_render_ft_glyph | 17:39.37 |
| | Robin_Watts: ^ | 17:39.41 |
| Robin_Watts | oh ass. | 17:39.44 |
| | what did I break? | 17:39.47 |
| | I see it. | 17:40.22 |
| | Force pushed a fix. | 17:41.18 |
| | back in a bit. | 17:42.23 |
| marcosw | Robin_Watts: you around? | 18:43.09 |
| tkamppeter | I have discovered a problem of the PostScript generated with pdf2ps of GS 9.05 not printing on Kyocera printers but the PostScript og 9.04 prints. | 19:01.06 |
| Robin_Watts | marcosw: back. | 19:01.54 |
| marcosw | Scott suggests that there might be a staff meeting in Texas in November. We need to lobby Miles to have it just after November 18th (scheduled date of the US GP in Austin). | 19:02.59 |
| Robin_Watts | ooh, nice. | 19:03.34 |
| | I'd mentioned the possibility of doing a meeting in Texas to coincide with that to scott 2 meetings ago. | 19:04.13 |
| henrys | marcosw:I'll need to dig out my bubba teeth. | 19:13.41 |
| marcosw | Robin_Watts: do you realize 12 out the 20 F1 races this year are held outside of europe? This is compared to 10 last year (I'm include Turkey in europe, even though the track is on the asian side of Istanbul). | 19:14.12 |
| Robin_Watts | marcosw: Indeed. | 19:18.18 |
| | and with valencia/barcelona set to alternate in future years, it's moving away from europe. | 19:18.46 |
| henrys | marcosw:a message to support from rubicon looks like it should go to Scott and Miles for a support contract. I suspect they are using gs legally but the page is german thought you could give it a once over, then see if it's worth bugging scott and miles about. | 19:22.49 |
| | rubicon.se | 19:23.03 |
| | rubicon.eu | 19:23.11 |
| | sorry | 19:23.12 |
| marcosw | I didn't see any email from rubicon.eu. There is a bug that they entered, is that what you mean? | 19:24.36 |
| henrys | oh right the bug is assigned to support | 19:25.19 |
| marcosw | they have an english language page: http://www.rubicon.eu/web/en/ | 19:26.36 |
| | seems to be identical to the german one. | 19:26.44 |
| Robin_Watts | Gah. Using a git bare repo is hurting my head. | 19:26.58 |
| | I've git fetched, and I now have master 2 commits behind origin/master | 19:27.18 |
| henrys | marcosw:Oh thanks then I'll handle it. | 19:27.21 |
| Robin_Watts | How can I update my master to origin/master? tor8? | 19:27.33 |
| marcosw | henrys: at least some of their products are open source, but I haven't figured out if they are GPL or something else. | 19:28.55 |
| | Lesser GPL <http://www.rubicon.eu/web/en/products/re-motion/> | 19:32.06 |
| tor8 | Robin_Watts: git push? | 19:32.39 |
| | that is, git push to your bare repo | 19:32.49 |
| | that's the normal use case at least | 19:32.57 |
| Robin_Watts | tor8: Pushing to my bare repo works fine. | 19:33.01 |
| | But I want to PULL from the main casper repo into my casper repo. | 19:33.18 |
| tor8 | I usually do that by pulling to a repo on my workstation and pushing back to my user repo on casper | 19:33.54 |
| Robin_Watts | I've got to assume it's possible to do without resorting to pushing from the other end. | 19:34.02 |
| tor8 | yes, but I think you need to do a lower level plumbing command | 19:34.22 |
| henrys | marcosw:I doubt there is anything there but I gave the info to scott anyway. | 19:34.23 |
| tor8 | to update the refs | 19:34.25 |
| | since a bare repo doesn't have HEAD | 19:34.37 |
| Robin_Watts | Hmm. When I had a non bare repo here, I always went origin -> casper -> {mac, windows, linux} | 19:34.40 |
| | I even tried: | 19:34.58 |
| | git update-ref res/heads/master refs/remotes/origin/master | 19:35.05 |
| | but that doesn't seem to do anything. | 19:35.12 |
| tor8 | yeah, update-ref is a bit tricky. I think it's happiest with sha1 sums | 19:35.55 |
| Robin_Watts | Right. git update-refs did it with an SHA. | 19:37.03 |
| | Can we please update git on casper? | 19:37.12 |
| tor8 | Robin_Watts: git reset --soft should work on a bare repo | 19:37.16 |
| Robin_Watts | It might be nice for us to make all our fz_print_ functions take a FILE *. | 19:44.32 |
| | Currently the text ones go to a FILE * but others go to stdout. | 19:44.53 |
| | Could I suggest that we move 'next' to be the first element of fz_text_style_s ? | 19:46.13 |
| | If we are going to publish the struct, and we intend to let the struct grow in future (see the /* etc */ comment) then presumably we should have the 'next' field in a place that won't move ? | 19:47.13 |
| | (In general, it's better for APIs to not publish structures, but to publish interfaces to get the information, but...) | 19:47.38 |
| | Why don't text+sheets follow the same len/cap/pointer structure as the other ones? | 19:50.18 |
| | fz_test_sheet_s, sorry. | 19:50.32 |
| | marcosw: Hmm. All the karmic stuff seems to be lost from the repos. How old is karmic koala? | 19:53.18 |
| marcosw | 10/2009 | 19:53.45 |
| Robin_Watts | And it was supported until April 2011. | 19:53.59 |
| | So we are now running an unsupported version on Casper. | 19:54.10 |
| mvrhel | Robin_Watts: when you have a second, I would like you to walk me through a function | 19:54.15 |
| marcosw | right, it's not one of the LTS distributens. | 19:54.18 |
| | ^tens^tions | 19:54.26 |
| Robin_Watts | marcosw: Is there a cunning ec2 way of upgrading easily ? | 19:54.37 |
| | (Can we clone to a new instance, and try to update that?) | 19:55.20 |
| marcosw | not as far as I can tell. at one point I was considering updating to 10.04, which is LTS, but chickened out. | 19:55.24 |
| Robin_Watts | http://alestic.com/2010/04/upgrading-servers-to-ubuntu-1004-lucid-on-amazon-ec2 | 19:56.26 |
| | If you are running an EBS boot Karmic instance, then it is possible to upgrade in place, but itâs also fine to simply start new instances. | 19:56.34 |
| | mvrhel: Sure. Go for it. | 19:57.19 |
| marcosw | I assume you'd like me to go ahead and update casper? | 19:57.30 |
| mvrhel | so I am up to mem_planar_get_bits_rectangle | 19:57.38 |
| Robin_Watts | I for one would think it would be worthwhile, but I'd like a consensus, so that when it breaks I don't get blamed :) | 19:57.59 |
| | We should bring it up at the meeting tomorrow. | 19:58.05 |
| mvrhel | which is getting called by clist_get_bits_rectangle after the 9 bands of data have been drawn for a particular line | 19:58.22 |
| Robin_Watts | Right. | 19:58.38 |
| marcosw | I'll read more about it, so that I can suggest how much effort it would be and what the risks are... | 19:58.39 |
| Robin_Watts | marcosw: Fab. | 19:58.47 |
| mvrhel | what I want, is for this function not to do any conversion to chunky | 19:58.49 |
| Robin_Watts | OK. | 19:58.55 |
| mvrhel | which is what it is currently doing for my case | 19:58.57 |
| | with 72 bits per pixel..... | 19:59.05 |
| Robin_Watts | OK. So let me look at clist_get_bits_rectangle. | 19:59.20 |
| mvrhel | I suspect I have an issue with the options set up | 19:59.27 |
| Robin_Watts | Yeah, the options passed in can say "give me the data in such and such a format" | 20:00.00 |
| mvrhel | right. so if I want the actually planar data back at my tiffsep device what do I need to set up? | 20:00.25 |
| Robin_Watts | You can ask for a particular plane, or you can ask for all the planes at once. If memory serves there is a planar or chunky bit. | 20:00.36 |
| | What is calling clist_get_bits_rectangle ? | 20:00.47 |
| mvrhel | gx_default_get_bits | 20:00.57 |
| | hold on let me give you the whole stack | 20:01.08 |
| | from tiffsep | 20:01.13 |
| | so in tiff set we are calling gdev_prn_get_bits -> gx_default_get_bits -> cliset_get_bits_rect_mt -> clist_get_bits_rectangle->mem_planar_get_bits_rectangle | 20:02.09 |
| | s/clistet/clist/ | 20:02.35 |
| | are the options getting set in gx_default_get_bits? | 20:03.36 |
| Robin_Watts | The get_bits device interface function doesn't have the options in. | 20:03.51 |
| mvrhel | I wonder if my tiff_sep device needs its own get_bits to set this | 20:04.09 |
| Robin_Watts | What should happen, I think, is that tiffsep should request the data in planar format. | 20:04.11 |
| | So you'd call gdev_prn_get_bits_rectangle with the appropriate flags. | 20:04.52 |
| mvrhel | ok. I will figure out how to get it there. If I want the data planar (and all of it) what do I need to set for an option? | 20:06.37 |
| Robin_Watts | (sorry, was called away) | 20:06.49 |
| | back now. | 20:06.54 |
| mvrhel | I am looking at the options in mem_planar_get_bits_rectangle | 20:07.32 |
| Robin_Watts | Hmm. I can't see a gdev_prn_get_bits_rectangle. | 20:07.39 |
| mvrhel | there is not one | 20:07.48 |
| | the call from gdev_prn_get_bits calls the default one, which is what the tiffsep is set up for | 20:08.25 |
| | this is where the options are set | 20:08.29 |
| | I think I need to have the tiff sep device have its own | 20:08.40 |
| Robin_Watts | gdev_prn_get_bits calls get_bits | 20:08.47 |
| mvrhel | so that it can set the proper options | 20:08.48 |
| | to call get_bits_rect (which is the clist proc) | 20:09.06 |
| Robin_Watts | No, you can do that direct in tiffsep | 20:09.08 |
| mvrhel | oh call get_bits_rectangle you mean directly | 20:09.38 |
| | with the proper options | 20:09.43 |
| Robin_Watts | yes. | 20:09.52 |
| mvrhel | gotcha | 20:10.02 |
| Robin_Watts | At the moment tiffsep calls the convenience function gdev_prn_get_bits, and that calls dev->get_bits, then it does some stuff to fiddle with the ends of the lines. | 20:10.17 |
| mvrhel | ok. so given that I fix that, what do I need to set option wise to get the planar data | 20:10.36 |
| | for the line | 20:10.48 |
| Robin_Watts | You could implement gdev_prn_get_bits_rectangle (that does exactly the same as gdev_prn_get_bits, but takes an options thing, and calls dev->get_bits_rectangle rather than dev->get_bits. | 20:11.32 |
| | So let me find the options. | 20:11.38 |
| mvrhel | oh yes | 20:12.00 |
| Robin_Watts | Look in gxbitfmt.h | 20:12.21 |
| | The #defines there are the bits in the bytes. | 20:12.47 |
| | So, what value is tiffsep currently passing ? | 20:13.00 |
| mvrhel | the options defined in the default proc | 20:13.14 |
| | PACKING_CHUNKY | 20:13.28 |
| Robin_Watts | (do you have a number to hand?) | 20:13.29 |
| mvrhel | a number to hand? | 20:13.42 |
| Robin_Watts | Yeah, if you've got it in the debugger you might have options = 0x12345 | 20:14.02 |
| mvrhel | ah | 20:14.08 |
| | yes | 20:14.21 |
| | 11710011 | 20:14.27 |
| | hex | 20:14.32 |
| Robin_Watts | OK, so it's asking for native representation, no alpha, chunky, | 20:15.35 |
| | copy,pointer, standard alignment, no offset, standard raster | 20:16.03 |
| | You have a choice. You could ask for a plane at a time, or you could ask for all the planes at once. | 20:16.47 |
| mvrhel | all the planes at once | 20:17.12 |
| Robin_Watts | Then GB_PACKING_PLANAR rather than GB_PACKING_CHUNKY | 20:17.30 |
| mvrhel | ok that is what I was thinking | 20:17.48 |
| Robin_Watts | At the moment it's saying that it will accept either a copy from the clients buffer, or it will accept pointers to the clients data. | 20:18.22 |
| | sorry, mistyped. let me try that again. | 20:18.37 |
| | At the moment the options say that the caller (the client) will be happy if the device proc either copies into the clients buffer, or it will accept pointers to the devices data. | 20:19.32 |
| mvrhel | how do you know what you will get? | 20:19.48 |
| Robin_Watts | If memory serves, what happens here is that one of the things you pass into get_bits_rectangle is a list of pointers. | 20:20.03 |
| mvrhel | yes | 20:20.14 |
| Robin_Watts | You set those up to point at your buffer, call the function, and either the device copies the data out, or it rewrites the pointers to point direct to the devices data. | 20:20.41 |
| | So if you then read from those pointers, either way you get the right data. | 20:20.57 |
| | Does that make sense ? | 20:21.02 |
| mvrhel | ah ok. that is clever | 20:21.10 |
| Robin_Watts | It's very clever. It's also TOO clever. | 20:21.23 |
| | The code in get_bits_rectangle is scary stuff. | 20:22.25 |
| | Best approached by prodding it with a sharp stick until it starts to work and then running away. | 20:22.43 |
| mvrhel | ok. thanks. I think I have enough information to push a bit further. so fare I have made it through the clist list. this get bits stuff is confusing. after I get this done, then it should be rather easy to create the sep and composite outputs | 20:23.13 |
| Robin_Watts | Cool. | 20:23.23 |
| mvrhel | then I need to see what happens with transparency, shadings and patterns.... | 20:23.31 |
| Robin_Watts | Right. there is a limit here... | 20:24.19 |
| | params | 20:24.40 |
| | gxgetbit.h | 20:25.23 |
| | line 42 | 20:25.30 |
| | We are limited to 32 pointers. | 20:25.52 |
| | Hence that's a hard limit on the number of planes you can get back requesting them all at once. | 20:26.12 |
| | If you look in doc/Drivers.htm it gives you the get_bits_rectangle call that's equivalent to a get_bits call - that may be a useful place to start. | 20:27.24 |
| mvrhel | Robin_Watts: ok thanks. | 20:35.17 |
| | have to step out for a bit | 20:35.24 |
| sebras | Robin_Watts: touch ~robin/repos/mupdf.git/git-daemon-export-ok please. :) | 23:22.53 |
| | Forward 1 day (to 2012/03/13)>>> | |
IRC Logs