| | <<<Back 1 day (to 2013/01/09) | 2013/01/10 |
| Robin_Watts | actually there may have been a problem with the rebuild. | 00:07.14 |
| rayjj | Robin_Watts: I'll have a look at the 'get_profile' calls to see if I can identify a problem. | 00:09.01 |
| Robin_Watts | what do you mean "identify a problem"? | 00:09.22 |
| | You mean beyond the obvious one? | 00:10.12 |
| | When we call 'get profile' from a render thread, and that forwards to the main threads device, we get a profile from the main threads set of devices - i.e. with the main threads allocator in. | 00:11.44 |
| | It's important that when we call 'get profile' from a render thread, that it should forward to the render threads copy of the device. Thus we'll get the equivalent profile from the render threads devices set of profiles - i.e. with the render threads allocator in. | 00:12.49 |
| | Changing cdev->target to ndev in that line does seem to have solved it. | 00:13.30 |
| | Does it solve it for you? | 00:13.35 |
| ray_laptop | Robin_Watts: debugging now... | 00:29.59 |
| JakeSays | is there a way to calculate the baseline of a font given a freetype ft_face instance? | 00:55.04 |
| | hmm. i s'pose given the bbox, baseline would be bbox.top + face ascender? | 00:56.40 |
| davef | In regards to bug 693538, how can I get gswin32c.exe, version 9.06, to use the updated gs_ttf.ps file? | 01:36.53 |
| tiuser | hello, just like to ask a question regarding resolutions (-r option). i have a pdf (http://www.scribd.com/doc/119727371/Test) which has 6.50" x 9.79" page size. when using -r300x300 and pngalpha device (to png) the output is a png with 1950x2938 dimensions and DPI is 299x299 (when viewed in WindowsXP properties, it is 300x300 in irfanview). just curious why is the height 2938 when it should be 7.79x300=2937 and 299x299? sorry and | 03:54.36 |
| alexcher | tiuser: How do you know the page size. Usually, PDF doesn't use decimals to express the size. I cannot download your file. Your site requires a Facebook account. | 04:30.17 |
| tiuser | @alexcher: page dimension is checked with adobe reader (shown in the bottom corner), you can use https://docs.google.com/open?id=0B7jG_hWyFOdJeG51bGpib1FUZDQ instead. thanks | 05:20.11 |
| alexcher | tiuser: AR can round up or down. This is not a proof. | 05:25.38 |
| | tiuser: The file is 468/72 by 705/72 inches, i.e.1950 by 2937.5 pixels at 300 dpi. Ghostscript is right. | 05:36.00 |
| tiuser | @alexcher: what is AR? also can you tell me how did you get 468 by 705 (what tool i can use, so i check the other files by myself)? thanks | 05:37.56 |
| alexcher | Acrobat Reader | 05:38.12 |
| | alexcher@lynx ~/g $ grep -a MediaBox <119727371-Test.pdf | 05:39.27 |
| | /MediaBox [0 0 468 705] | 05:39.28 |
| tiuser | @alexcher : got it. thanks very much. | 05:41.03 |
| kens | chrisl just encountered a major surprise. It seems that in the current code, ps2write always emits all colours in a device space. So it doesn't preserve Separation or DeviceN colour spaces !! | 09:06.06 |
| chrisl | Oh, that's not good - I'm surprised we haven't heard about that before..... | 09:07.37 |
| kens | Lets say it was something of a surprise.... | 09:07.52 |
| | I realised I'd omitted the case fomr my new code, so I went back to see how the old code coped. Abswer; it doesn't | 09:08.18 |
| chrisl | Well, at least you know about it now | 09:09.23 |
| kens | Yes, I've fixed it in the new code, it wasn't hard, OPDFRead already caters for it, but really.... | 09:09.45 |
| chrisl | BTW, I had a quick look at CIDFont support, and it's not going to be too easy :-( I didn't realise that in PDF CID Type 2 fonts are really just Truetypes- - nothing like a PS CID Type 2 :-( | 09:13.20 |
| kens | AH, well that probably explains why it hasn't been done before | 09:13.40 |
| chrisl | I *think* basic support can be done with some tweaking of the existing TTF->Type42 code. *But* I don't know how that will handle fonts with large numbers of glyphs. | 09:15.03 |
| kens | We always emit subsets I think, so I don't think that's hugely likely | 09:15.29 |
| | I have a vague memory that we never emit fonts with > 255 glyphs, but that could be me being mistaken | 09:15.55 |
| chrisl | Doesn't the "don't subset" directive affect ps2write? | 09:16.15 |
| kens | It doesn't affect pdfwrite IIRC | 09:16.31 |
| | I think we ignore it for TT fonts | 09:16.42 |
| | I believe there's an open bug report about it | 09:16.54 |
| | see #689236 | 09:17.36 |
| chrisl | Oh, well, I only spent about a half hour looking at it - the OPDFread Postscript is not formatted for readability! | 09:17.36 |
| kens | The OPDFRead code is horrible, but there's a more readable version in resources somewhere (assuming you are reading the outptu header at the moment) | 09:18.22 |
| chrisl | Yeh, I'll look at it again when I have some time spare. I still think CIDType 1 fonts will be pretty easy, but they are pretty rare in PDFs there days | 09:19.38 |
| kens | FWIW hte hard-coded number of glyphs before we enforce subsetting is now 4096 | 09:20.04 |
| chrisl | kens: does the OPDFRead TTF code handle streams > 64k? I assume it must | 09:24.11 |
| kens | chrisl I have absolutely no idea.... | 09:24.23 |
| | But I would assume it does, otherwise image streams would be a major problem | 09:24.54 |
| chrisl | Good point. I'll check that next time I look at it. I've seen plenty of basic "western" TTF with glyf tables > 64k, so..... | 09:25.52 |
| | Anyway, I have a squash match - back in a couple of hours...... | 09:27.05 |
| kens | Have fun... | 09:27.13 |
| chrisl_away | ta! | 09:27.21 |
| kens | Hmm, cluster locked up for me | 10:41.20 |
| | Or maybe just dashboard | 10:59.33 |
| | Robin_Watts : ping | 11:03.45 |
| Robin_Watts | pong | 11:10.59 |
| kens | Robin_Watts : I think the dashboard for cluster is broken | 11:25.13 |
| | sitting at 8% but job is compelte | 11:25.29 |
| Robin_Watts | looks fine to me. I just launched a cluster job. | 11:25.32 |
| | Have you closed/reopened the page ? | 11:25.42 |
| kens | THenits only for me on Firefox, weird | 11:25.42 |
| | No, Il;l do tht | 11:26.22 |
| | same, must be cached | 11:26.36 |
| Robin_Watts | Try restarting firefox ? | 11:27.04 |
| kens | Yeah, will try in a moment | 11:28.27 |
| | Nope, still exactly the same, I guess it is *still* cached | 11:29.15 |
| Robin_Watts | The page itself isn't fetched. | 11:29.35 |
| | Shift reload repeatedly? | 11:29.43 |
| | shift reload should tell it to ignore any caches along the way. | 11:29.58 |
| kens | Chrome shows it OK so its just FF | 11:31.21 |
| | Never mind, I guess it will get better eventually | 11:31.40 |
| | OK clearing teh cache manually sorted it | 11:33.15 |
| Robin_Watts | gets linkedin mail from Simon Birtwistle at Global. I'm not sure I know him. | 11:47.06 |
| kens | I do | 11:49.40 |
| | Or did | 11:49.44 |
| Robin_Watts | kens: OK. I see how our spheres interact. Thanks. | 11:53.20 |
| kens | :-) | 11:53.29 |
| | Hmm 17 or so files that still seg fault. Lunch time I think | 12:19.36 |
| jzmer | if someone asked me how ghostscript distinguished itself from adobe's distiller/livecycle pdf generator, how was I supposed to respond besides mentioning the obvious ridiculous level of adobe's pricing and fsf/gnu? | 12:20.42 |
| Robin_Watts | jzmer: We've been around for 30 years and have a dedicated team updating and fixing bugs, so we are not some low quality cheap alternative. | 12:33.53 |
| | And we have a large customer list of big industry players, so we're in lots of famous brand printers that you might not realise. | 12:34.46 |
| jzmer | right! and adobe don't normally "update" their products beyond a certain amount of time, i could also add! and even you purchased a new product, that would come as a new install, not a patch! hence administrative difficulties! | 12:36.18 |
| | Robin_Watts: thanks for the reminder on maintenance! | 12:37.29 |
| | Robin_Watts: i could even go on a tirade against adobe on the perspective of product patching on obsolete platforms. | 12:44.43 |
| | and even extending to things such as display postscript | 12:45.25 |
| Robin_Watts | casper is unusably broken. | 12:53.11 |
| | by which I mean, I can't run emacs. | 12:53.18 |
| kens | I can't run emacs on anything ;-) | 12:53.35 |
| davef | In regards to bug 693538, how can I get gswin32c.exe, version 9.06, to use the updated gs_ttf.ps file? | 14:05.40 |
| dlty | hello | 14:11.01 |
| ghostbot | salut, dlty | 14:11.01 |
| dlty | I have a question regarding MuPDF on Android, it doesn't support hyperlinks? | 14:11.30 |
| Robin_Watts | davef: I suspect that file is built into gs. So easiest answer is that you need to rebuild with the latest version. | 14:12.01 |
| | dlty: The code is there, it's disabled in the current release. | 14:12.15 |
| dlty | Robin_Watts: I see. Why is it disabled? And could you point me to it's location? | 14:12.49 |
| Robin_Watts | dlty: Because we didn't have a nice interface for enabling/disabling links etc. | 14:13.21 |
| | I think we now do. It should be enabled in the next release. | 14:13.33 |
| dlty | Hm, I don't need one, just need it to launch a browser intent (which I can probably do from Java) | 14:14.10 |
| davef | Thanks | 14:22.23 |
| paulgardiner | dlty: in MuPDFActivity.java search for "Clicked on an external" | 14:26.13 |
| dlty | paulgardiner: I see it, thank you | 14:30.36 |
| Robin_Watts | dlty: If you come up with changes that make hyperlinks properly invoke the links, we'd love to see them. | 15:20.06 |
| | mvrhel_laptop: Morning. | 15:20.11 |
| mvrhel_laptop | Morning Robin_Watts | 15:20.20 |
| dlty | Robin_Watts: will do | 15:25.14 |
| | hm, I'm having a compile error with the 3rd party libs .. got everything from git .. make: *** No rule to make target `build/debug/opj_bio.o', needed by `build/debug/libopenjpeg.a'. Stop. | 15:27.34 |
| | anyone have any ideas on why this is happening? full log: http://pastie.org/private/zlltglvb9cczhtn4g8o5q | 15:28.55 |
| Robin_Watts | dlty: You're building from git? | 15:29.17 |
| | Have you done: git submodule update --init ? | 15:29.28 |
| dlty | Yeah, I checked out all the submodules and updated them | 15:29.47 |
| Robin_Watts | What SHA are you on? | 15:30.21 |
| dlty | This is my list: http://pastie.org/private/sxyk0hzqej2hxoxvtkmja | 15:31.15 |
| Robin_Watts | oh, great. We can't use 'com.artifex.mupdf' because it already exists in google play :( | 15:31.17 |
| | dlty: Right, I meant for mupdf itself. | 15:31.33 |
| dlty | ah, that'd be 9ed0aa9c0b4dce36530f41f950e94bfe4d9133bc | 15:32.03 |
| | so, head/master | 15:32.08 |
| Robin_Watts | Right, so why is thirdparty/openjpeg on 2.0.0-29 ? | 15:32.38 |
| dlty | hm, good question lol. should be 1.5 yes? | 15:32.57 |
| Robin_Watts | Do: git submodule update --init | 15:33.05 |
| | and that will update them all to the correct point. | 15:33.17 |
| dlty | Hm, I think I screwed up something with the copy somehow (this is embedded in another repo) .. but I know what the problem is then, thanks | 15:34.24 |
| Robin_Watts | tor8, paulgardiner: ping | 15:35.17 |
| | sebras: ping | 15:35.28 |
| tor8 | Robin_Watts: echo echo echo | 15:35.51 |
| kens2 | Robin_Watts : any idea which machines have a copy of the cluster tests ? | 15:35.56 |
| paulgardiner | hi | 15:36.01 |
| Robin_Watts | kens2: urm... all of them? They can hardly test without them. | 15:36.18 |
| | So I just did a release build and signed it. | 15:36.30 |
| kens2 | WHere do we keep the tests then ? | 15:36.39 |
| | I can't find the one I wan ton peeves | 15:36.50 |
| Robin_Watts | Tried to upload it to our google account, and got told that I couldn't, because someone has already used com.artifex.mupdf | 15:37.01 |
| tor8 | Robin_Watts: who's using com.artifex.mupdf in google play? | 15:37.01 |
| Robin_Watts | kens2: /home/marcos/cluster/{tests,tests_private} | 15:37.21 |
| | tor8: No way of knowing. | 15:37.26 |
| dlty | Robin_Watts: https://play.google.com/store/apps/details?id=com.artifex.mupdf | 15:37.43 |
| tor8 | Robin_Watts: one would think that checking that an apps domain is owned by the submitter would be part of the approval process... | 15:37.45 |
| kens2 | ah, was missing hte 'cluster' thanks | 15:37.47 |
| dlty | tor8: there is no approval process ;) | 15:37.56 |
| tor8 | dlty: ah, here's me thinking google is also playing the walled garden game... | 15:38.23 |
| dlty | Robin_Watts: you can contact Google and they'll probably have it revoked / renamed however. | 15:38.25 |
| tor8 | Robin_Watts: customer of ours? | 15:39.55 |
| Robin_Watts | no afaik | 15:40.04 |
| | tor8, paulgardiner, sebras, henrys: So, what do we do? | 15:42.16 |
| tor8 | Robin_Watts: break out the torches and pitchforks ;) | 15:42.34 |
| Robin_Watts | Do we change to com.artifex.mupdf1.1 or something ? | 15:42.38 |
| tor8 | Robin_Watts: or use com.mupdf.demo1 or something? | 15:42.58 |
| Robin_Watts | com.artifex.mupdf.demo ? | 15:43.15 |
| | I do think that we should be the only people using com.artifex.* | 15:43.30 |
| kens2 | Given artifex is our trademark we may be able to enforce that | 15:44.16 |
| tor8 | Robin_Watts: I think so too. maybe we should change the source to be com.example.mupdf just to prevent these issues with incompetent people who rip off the code without knowing what they do. | 15:44.20 |
| | I mean, any half competent thief would know to cover their tracks at least a little bit | 15:44.40 |
| Robin_Watts | tor8: I suspect that once we get our hands on com.artifex.mupdf under google play, we should be fine. | 15:45.07 |
| tor8 | Robin_Watts: still, we should probably change the source files to com.example.* | 15:45.38 |
| Robin_Watts | So... let me fire off a mail to the developer, asking him to remove/rename his app, and another to google. | 15:45.48 |
| | tor8: really? So then we'd need to rename them every time we build for the store? | 15:46.05 |
| tor8 | Robin_Watts: I haven't found a link to download their source, have you? | 15:46.09 |
| Robin_Watts | That seems unreasonable to me. | 15:46.16 |
| tor8 | Robin_Watts: make it part of the build script? | 15:46.20 |
| | and pull the domain to use out of .gitconfig or something similar | 15:46.36 |
| Robin_Watts | tor8: java doesn't work like that. | 15:47.03 |
| | Hence the source is in: android/src/com/artifex/mupdf/ | 15:47.22 |
| dlty | If you own the domain artifex.com you should be able to claim it from the Google store | 15:47.23 |
| tor8 | oh... so it's using the java package name? eww. | 15:47.27 |
| dlty | tor8: yeah, it's the entire application package name | 15:47.55 |
| paulgardiner | Renaming the source to com.example.mupdf might allow us to have both the Play version and a development version on a device simultaneously, which might be useful | 15:48.11 |
| tor8 | Robin_Watts: I thought only the AndroidManifest.xml instance of the name was used | 15:48.12 |
| kens2 | dlty we ownartifex.com and Artifex is our trademark too | 15:48.21 |
| dlty | kens2: then go beat up some newbs | 15:48.33 |
| kens2 | I'm reasonably sure we cna claim it | 15:48.38 |
| | Actually MuPDF is our trademark too of course D'oh | 15:49.19 |
| tor8 | kens2: we can probably do a DMCA takedown, due to GPL violation as well (unless they are a customer... which I don't believe they are) | 15:49.42 |
| kens2 | Probably alos true, but 'passing off' is not legal in the US either. | 15:50.10 |
| dlty | I wouldn't go that far, probably just an honest mistake. | 15:50.11 |
| kens2 | So using any of our trademarks is Bad | 15:50.23 |
| dlty | Only someone who's very new to android development would make such a mistake really | 15:50.33 |
| tor8 | dlty: honest mistake? how is not complying with with GPL an honest mistake? | 15:50.59 |
| kens2 | How very odd. My new colour code seems to result in thousands of differences. Almost all are 1-pixel shifts in text position...... | 15:51.31 |
| dlty | fine, -honest | 15:51.34 |
| sebras | Robin_Watts: pong. *reading logs* | 15:53.15 |
| henrys | we certainly want to report smart engagement llc to miles - that is the company using our names right? | 15:54.24 |
| Robin_Watts | http://smartibook.ndot.in/ | 15:55.02 |
| henrys | any evidence it actually uses mupdf? | 15:58.37 |
| dlty | I can grab it and logcat it, it'll show on the logs | 15:59.30 |
| henrys | bbiab, it says it won't work on my nexus. | 15:59.33 |
| sebras | tor8: once you take over com.artifex.mupdf and fix the source, it looks like searching for com.example.mupdf would be an easy way of spotting GPL violations then..? | 15:59.59 |
| Robin_Watts | henrys: The fact that it's java class is com.artifex.mupdf? :) | 16:00.01 |
| henrys | we did have a magazine customer | 16:01.30 |
| | could this be them? | 16:01.37 |
| | before we try and convict. | 16:02.23 |
| Robin_Watts | henrys: The magazine publisher customer that we had a few weeks ago? | 16:02.37 |
| paulgardiner | Could be - the one that we put link following in for and single page view of multiple docs | 16:02.48 |
| Robin_Watts | The one that Paul helped out while we were at the last staff meeting? | 16:02.49 |
| | That was NOT them. | 16:02.54 |
| paulgardiner | We should ask that customer to avoid using com.artifex.mupdf | 16:03.30 |
| Robin_Watts | paulgardiner: Well, presumably they can't be using that as SmartIBook already are ?) | 16:03.54 |
| paulgardiner | :-) Doh! I just thought that as I finished typing | 16:04.15 |
| | ... but if they have yet to get their stuff on Play... | 16:04.41 |
| | I wonder how many other PDF viewer authors have used the MuPDF library but been cleverer with the Java. | 16:06.00 |
| Robin_Watts | paulgardiner: Many, I'm sure. | 16:06.26 |
| | and if they are following the terms of the GNU GPL that's fine. | 16:06.43 |
| sebras | Robin_Watts: or they are paying. | 16:07.10 |
| paulgardiner | Yeah, but I meant without even acknowledging. | 16:07.16 |
| tor8 | paulgardiner: Robin_Watts: loads, I would imagine, given the number (and sadly, quality, or lack thereof rather) of questions on stackoverflow | 16:09.36 |
| henrys | so somebody needs to write them up and send it to Miles and Scott so they can have a go at them sales wise while telling them not to use our names. | 16:12.41 |
| Robin_Watts | I'm writing the email now | 16:12.54 |
| | ray_laptop: So, did that change check out? | 16:39.59 |
| ray_laptop | Robin_Watts: I got sucked into working on something for Len and will be getting back to it | 16:41.28 |
| Robin_Watts | ray_laptop: Fair enough. | 16:41.40 |
| | I've stopped work on it, believing it to be fixed. If there are still problems, please let me know. | 16:42.04 |
| | presumably we should get marcosw1 to run a test with the fix in? | 16:42.26 |
| dlty | Robin_Watts: is there any plans to address the out of memory errors when zooming on Android? it's getting quite painful. I know it's related to creating the bitmaps to display on screen but it seems they're never recycled | 16:49.03 |
| Robin_Watts | dlty: It's not a problem we've seen. | 16:49.36 |
| dlty | I can reproduce it easily on an Asus transformer pad | 16:50.17 |
| | granted, that's a 1920x1080 tablet but the Nexus 10 has an even higher resolution | 16:51.05 |
| Robin_Watts | I have an Asus transformer pad. | 16:53.10 |
| dlty | okay, I can provide a stack trace if you'd like | 16:53.54 |
| | http://pastie.org/pastes/5662538/text?key=k4irihohqrj1sfulrgv3jq shows the issue (my application uses maybe 15-20 MB, the rest is mupdf) | 16:55.57 |
| Robin_Watts | dlty: Have you tried adding the recycle calls to the bitmaps? | 16:56.52 |
| dlty | Robin_Watts: I'm doing so right now ;) | 16:58.44 |
| mvrhel_laptop | Robin_Watts: were you going to commit your fix for the MT problem? | 16:58.46 |
| Robin_Watts | mvrhel_laptop: I was waiting for ray to indicate the results of his testing. | 16:59.15 |
| mvrhel_laptop | sounds like a good idea | 16:59.24 |
| Robin_Watts | I have put the patch on the bug. | 16:59.27 |
| mvrhel_laptop | ok great | 16:59.33 |
| dlty | Robin_Watts: adding the recycle calls helps (hasnt crashed yet). Should I open an issue and send a patch? | 17:09.46 |
| Robin_Watts | That would be much appreciated, thanks. | 17:10.00 |
| kens | Night folks | 17:15.04 |
| mvrhel_laptop | Robin_Watts: you there? | 17:20.27 |
| Robin_Watts | I am# | 17:20.35 |
| mvrhel_laptop | so I am playing around still with the metro app viewer | 17:23.26 |
| | or winapp what ever you want to call it | 17:23.48 |
| | so fz_open_file uses _wopen for WIN32 | 17:24.07 |
| Robin_Watts | It does. | 17:24.28 |
| mvrhel_laptop | and, this restricts me to only opening files in the apps install directory | 17:25.10 |
| Robin_Watts | right. | 17:25.20 |
| | If we used a FILE * (and hence fopen) would that help? | 17:25.35 |
| mvrhel_laptop | if I make use of their file picker stuff, I can go anywheere | 17:25.38 |
| Robin_Watts | I'm not sure why tor8 chose open/wopen rather than FILE *'s. | 17:26.10 |
| | does their file picker stuff use FILE *'s or ints ? | 17:26.47 |
| tor8 | Robin_Watts: because we do our own layer of buffering, it felt rather superfluous to buffer twice | 17:26.58 |
| | call it premature optimization if you will | 17:27.17 |
| Robin_Watts | tor8: And you believe FILE *'s have more buffering in than fd's ? | 17:27.23 |
| mvrhel_laptop | Robin_Watts: let me poke around a bit more on opening with their file picker syntax and then I will get back to you on this shortly.... | 17:27.49 |
| tor8 | Robin_Watts: they might. fd's get your raw syscalls, FILE* adds its own layer of buffering. | 17:28.02 |
| Robin_Watts | mvrhel_laptop: Can you give me a file picker function I can google for please? | 17:28.14 |
| tor8 | Robin_Watts: probably not even noticeable though... if you feel strongly about it we can easily move to FILE* | 17:28.27 |
| | mvrhel_laptop: it's fairly easy to add another fz_stream type wrapping anything with a few function pointers in a struct. so if metro exposes some odd windows only file handles, you can make use of those too. fz_open_document_with_stream can be used then. | 17:29.50 |
| | Robin_Watts: or if we want to go less portable, we could have just used mmap on the file and not worry at all about seeking for reads. | 17:30.23 |
| mvrhel_laptop | Robin_Watts: this is the c++ object I have to work with | 17:30.34 |
| | http://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.storagefile.aspx | 17:30.36 |
| Robin_Watts | mvrhel_laptop: So... you use the filepicker to get a StorageFile, and then OpenASync that to get an IRandomAccessStreamWithContentType? | 17:33.05 |
| | and IRandomAccessStreams get you to IInputStreams ? | 17:34.42 |
| mvrhel_laptop | Robin_Watts: I have not done that yet. Only thing I have done is played around to open files that were in the app directory to make sure I was ok with mupdf. That works fine. I was thinking that I would want to use the OpenASync operator but I was trying to think about how to do this with mupdf in a way that is clean and useful for the future | 17:34.45 |
| Robin_Watts | mvrhel_laptop: Well, mupdf has it's own 'stream abstraction' fz_stream. | 17:35.26 |
| mvrhel_laptop | I see that | 17:35.37 |
| Robin_Watts | If you can wrap the metro streams up as one of those, then you can use fz_document_open_stream. | 17:36.05 |
| | fz_document_open essentially just implements such an fz_stream on top of a file. | 17:36.42 |
| mvrhel_laptop | ok. let me play around with that for a bit | 17:37.08 |
| | Thank Robin_Watts | 17:38.22 |
| henrys | trying out vs 2012 gp_stdia.h includes time_h which in turn can't find time.h | 17:53.02 |
| | actually can't find sys/time.h - so that is expected and HAVE_SYS_TIME_H shouldn't be set hmmph | 17:55.11 |
| | ah nvm I see it. | 17:55.34 |
| Robin_Watts | marcosw: casper is broken. | 18:15.48 |
| | emacs won't start on it. | 18:16.09 |
| | emacs: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory | 18:16.24 |
| marcosw | Maybe emac is broken and casper is okay? | 18:16.52 |
| Robin_Watts | Without emacs, casper is unusable :( | 18:17.09 |
| marcosw | seriously, emacs probably broke after the upgrade to 12.04.1 LTS. give me a sec. | 18:17.26 |
| | Robin_Watts: sorted. | 18:20.14 |
| | I think. emacs starts at least, but I don't use it so can't further test it. | 18:20.28 |
| Robin_Watts | Thanks. | 18:20.40 |
| marcosw | does complain about lisp not begin found, which I'm looking into | 18:21.39 |
| henrys | bbiab | 18:35.46 |
| liucougar | hi all, i submitted a enhancement report with a patch http://bugs.ghostscript.com/show_bug.cgi?id=693545 | 18:39.34 |
| | i am wondering whether anyone would be able to review it and give me some feedback | 18:40.13 |
| mvrhel_laptop | bbiab | 18:53.03 |
| dlty | Robin_Watts: as mentioned: http://bugs.ghostscript.com/show_bug.cgi?id=693546 | 19:04.06 |
| mvrhel_laptop | Robin_Watts: you still there? | 19:17.11 |
| Robin_Watts | I am. | 19:17.20 |
| | liucougar: Does -ggg not already do that ? | 19:17.53 |
| mvrhel_laptop | so, you are saying that I can wrap up the windows stream object into the fz_stream_s and set it up with fz_new_stream | 19:18.25 |
| Robin_Watts | mvrhel_laptop: That's my uninformed opinion, yes :) | 19:18.55 |
| mvrhel_laptop | ok is there a reason that fz_new_stream does not set up seek? | 19:19.06 |
| Robin_Watts | because not all streams are seekable. | 19:19.31 |
| | You can set stream->seek yourself. | 19:19.46 |
| mvrhel_laptop | Iine ok | 19:19.50 |
| | oop | 19:19.53 |
| | s | 19:19.55 |
| | ok | 19:19.57 |
| | gotcha | 19:20.00 |
| | well I have the windows stream object now, so let me see what I can do from there | 19:20.45 |
| | I don't understand ray's comments in his email | 19:25.18 |
| | I would think the target device would be the thread | 19:25.29 |
| | threads device. do you understand Robin_Watts ? | 19:25.48 |
| Robin_Watts | am looking. | 19:25.56 |
| | When I first tested the change, it did not fix it. I suspect it was just finger trouble, cos when I rebuilt and retested it worked. | 19:27.31 |
| mvrhel_laptop | ok | 19:30.01 |
| ray_laptop | Robin_Watts: mvrhel_laptop: on linux using, 'ndev' gives 'gx_device' has no member named 'target', thus you need 'ncdev' | 19:39.18 |
| dlty | Robin_Watts: is there a good reason why links are only enabled once you tap the link icon on the top (Android) and not generally enabled? | 19:39.38 |
| Robin_Watts | I wasn't using ndev->target. | 19:39.41 |
| | I was using ndev | 19:39.44 |
| | dlty: because we feel that having links enabled without them being highlighted as being enabled is potentially confusing. | 19:40.22 |
| | I don't want to accidentally hit a link while trying to pan or zoom. | 19:40.52 |
| ray_laptop | hmm... well, using ncdev->target fixed it. I wonder why. Let me try 'ndev' as the target for the buf_device and make sure that also fixes it for me. | 19:40.53 |
| dlty | ah I see. I personally don't mind that aspect | 19:41.34 |
| | But I was able to launch the browser correctly (any other link should launch as well, such as file:// or even appname:// if they've registered the protocol handler). I will submit another patch | 19:42.40 |
| | Also link handling should come before the margin-tap handling imho | 19:44.29 |
| mvrhel_laptop | ray_laptop: so I don't understand why the gx_forward_get_profile would be getting the profile from the main thread and not the individual thread | 19:48.53 |
| Robin_Watts | mvrhel_laptop: With the *existing* code, it was forwarding to the main threads device. | 19:49.22 |
| mvrhel_laptop | Robin_Watts: or will you fix keep that from happending | 19:49.24 |
| Robin_Watts | hence it was getting the profile from the main thread. | 19:49.30 |
| | with the new fix, it forwards to the cloned device, and everything now works as we expect. | 19:49.49 |
| mvrhel_laptop | I understand that. reading ray's email it sounds like it still will be happening | 19:49.49 |
| | ok | 19:49.53 |
| rayjj | mvrhel_laptop: it gets it from the ppmraw device dev->icc_struct and that has the device profile with the main thread's 'memory' pickled into it | 19:50.11 |
| mvrhel_laptop | rayjj: even after Robin's fix? | 19:50.38 |
| Robin_Watts | dlty: Do we need the first part of your patch? | 19:51.17 |
| dlty | Currently you don't do anything with external links | 19:51.57 |
| rayjj | with the change it gets the profile from the cloned device (using gx_default_get_profile on the 'ndev', and that one has the correct 'memory' for the thread) | 19:52.01 |
| Robin_Watts | dlty: I mean the recycle patch. | 19:52.10 |
| rayjj | mvrhel_laptop: no, not after Robin_Watts' fix | 19:52.16 |
| dlty | I will submit and you can assess / pick what changes to introduce | 19:52.29 |
| | Ah, yes | 19:52.34 |
| | My TF Prime hasn't crashed since | 19:52.53 |
| Robin_Watts | old_bm.recycle(); looks fine to me, just before we set old_bm = null; | 19:52.55 |
| mvrhel_laptop | ok. that makes sense. the way your email was worded it sounded to me like there was a problem with gx_forward_get_profile | 19:52.57 |
| | which I did not understand | 19:53.21 |
| Robin_Watts | but the additional call to h.getBm(); - do we really need that? | 19:53.24 |
| dlty | yes, that's what I added, it wasn't there | 19:53.25 |
| | Yes because you also want to clear the bitmap that's currently being displayed (since you're now generating a new one) | 19:53.59 |
| Robin_Watts | dlty: OK. | 19:54.53 |
| | I wonder if there is a danger that we might be clearing it too early? | 19:55.10 |
| dlty | that reference will likely be GC'd now that the bitmap is flagged for recycling and you're replacing it in the holder | 19:55.17 |
| | the OS doesn't clear it immediately and you're already replacing it on screen the next couple lines so should be no problem | 19:55.44 |
| Robin_Watts | right. it's the fact that the next couple of lines might take a long time to run. | 19:56.05 |
| dlty | it basically sets a flag that the GC engine can get rid of it.. if there's still an active reference to it, nothing happens | 19:56.40 |
| Robin_Watts | I think I'd prefer a change to BitmapHolder | 19:56.51 |
| dlty | (when the GC runs that is) | 19:56.55 |
| Robin_Watts | In setBm... | 19:57.00 |
| dlty | well that doesn't solve the problem though, because at that time you have two full screen bitmaps in memory | 19:57.38 |
| Robin_Watts | Bitmap old = bm; bm = abm; if old != bm old.recycle(); | 19:57.50 |
| dlty | and possibly three if the user zooms again quickly | 19:57.58 |
| Robin_Watts | right. we'd only be recycling once the new one was in place. | 19:58.14 |
| | actually, drawPage is synchronised, so I think we should be OK. | 19:59.03 |
| dlty | see: http://developer.android.com/reference/android/graphics/Bitmap.html#recycle() | 19:59.12 |
| Robin_Watts | OK. Let's just go with your fix. | 19:59.18 |
| dlty | explains it better than I can | 19:59.18 |
| | up to you | 19:59.23 |
| | :) | 19:59.24 |
| Robin_Watts | I did understand bitmap recycling - I looked it up a while ago when someone else pointed it out, but I'd never seen the problem arise, so I forgot about it. | 20:00.00 |
| dlty | Sure, no problem | 20:00.19 |
| | I think the more graphical documents cause the problem fairly easily | 20:00.43 |
| Robin_Watts | dlty: Actually, I am confused here. | 20:03.38 |
| | Why not just do h.setBm(null); ? | 20:03.58 |
| dlty | tell me | 20:04.06 |
| Robin_Watts | That will remove the last reference to the bitmap, and allow it to be gc'd. | 20:04.18 |
| dlty | because setting the object to null won't work with Bitmaps | 20:04.28 |
| Robin_Watts | According to the specs you just gave me: This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap. | 20:05.15 |
| dlty | It will once you finish the activity and/or fragment you're working with, yes. Which you don't. | 20:05.56 |
| Robin_Watts | The only reference to the object is in the bitmap holder. | 20:06.22 |
| | I can see that there is value in ditching the reference before calling 'Bitmap.createBitmap' as it stops there being 2 copies hanging around. | 20:06.56 |
| | Can you do a quick test please? | 20:07.38 |
| | Instead of doing: Bitmap old_bm = h.getBm(); if (old_bm != null) old_bm.recycle(); | 20:08.03 |
| dlty | I forget why but I know it's related to how they're stored in memory, they won't be destroyed by the GC by clearing the reference only | 20:08.08 |
| | Sure, I can do that | 20:08.16 |
| Robin_Watts | just do: h.setBm(null); | 20:08.18 |
| | and see if that solves the problem. | 20:08.31 |
| rayjj | I see why ncdev->target fixes it as well. When the 'ndev' is set up as a command list, (from gdev_prn_allocate_memory) it sets it's 'target' to itself (done by clist_init_params macro), thus using gx_forward_get_profile does not reference the main thread's device structure. | 20:08.51 |
| liucougar | Robin_Watts: no, it considers objects with streams different from others | 20:08.52 |
| Robin_Watts | liucougar: OK. I quickly scanned the patch and it looked plausible. I'll have a proper look tomorrow. | 20:09.41 |
| rayjj | Robin_Watts: but I agree that just 'ndev' in the create_buf_device call is preferable to 'ncdev->target' | 20:09.42 |
| | Robin_Watts: are you going to commit the change ? | 20:09.52 |
| liucougar | Robin_Watts: cool, thanks | 20:09.57 |
| | Robin_Watts: let me know if you need anything | 20:10.04 |
| Robin_Watts | rayjj: You can, or I will tomorrow. | 20:10.11 |
| dlty | Robin_Watts: this answer explains what I meant: http://stackoverflow.com/a/4959900/295103 | 20:11.24 |
| rayjj | Robin_Watts: I don't know when marcosw1's next scheduled MT rendering run is. I wouldn't want to miss it if it is tonight. | 20:11.24 |
| Robin_Watts | rayjj: Go for it then. | 20:11.39 |
| dlty | so < API 11, the bitmaps will be 'sticky', causing the issue even if you just set it to null. On ICS (API 15) however, setting it to null fixes the issue | 20:12.14 |
| Robin_Watts | dlty: ok. | 20:12.39 |
| | so I'm back to preferring a fix (at least partially in) BitmapHolder | 20:13.19 |
| | We h.setBm(null); before the createBitmap | 20:13.44 |
| dlty | You could call recycle in the holder | 20:13.47 |
| Robin_Watts | and we have setBm call recycle in the holder. | 20:13.53 |
| dlty | yup | 20:13.58 |
| Robin_Watts | dlty: http://pastebin.com/byxdmPfc | 20:17.08 |
| | How's that look? | 20:17.11 |
| | http://pastebin.com/crLri4bG | 20:18.25 |
| | Better | 20:18.27 |
| dlty | if both objects are the same, why are you still assigning one to the other :P | 20:19.47 |
| Robin_Watts | You'd like an 'else' ? :) | 20:20.24 |
| dlty | just http://pastebin.com/PdraiYW3 | 20:20.27 |
| Robin_Watts | That will never set bm to be non NULL :) | 20:20.59 |
| | bm is null on entry, so it never gets set. | 20:21.28 |
| dlty | derp, ok lol | 20:21.30 |
| | yours is fine I suppose | 20:22.58 |
| | also just added: http://bugs.ghostscript.com/show_bug.cgi?id=693547 | 20:23.45 |
| ray_laptop | Robin_Watts: Thanks again. I just committed the fix (I didn't bother with a clusterpush before since it doesn't do NumRenderingThreads > 0) | 20:26.35 |
| Robin_Watts | ray_laptop: Fab. | 20:26.43 |
| | tor8: Various reviewy things - some you may have looked at before. | 20:28.20 |
| | dlty: That should make it's way through the review process within a couple of days. I'll update the bug when it gets there. Thanks. | 20:28.45 |
| dlty | you're welcome | 20:28.58 |
| liucougar | i am interested in improving rendering performance (rendering to images) of mupdf in amd64 systems | 20:31.43 |
| | i am wondering how much work it will be to use modify mupdf to use something like IPP | 20:32.27 |
| | s/use// | 20:32.41 |
| Robin_Watts | liucougar: Are you concerned about the time spent scaling images? | 20:37.00 |
| | or some other thing. | 20:37.08 |
| Robin_Watts | heads to dinner. will check logs later. | 20:37.16 |
| liucougar | Robin_Watts: i have not profiled it, so i am not sure where it spends most of the time | 20:37.33 |
| | i think scaling is probably a quite expensive one | 20:38.03 |
| | my goal is to achieve as fast rendering of pdf pages as possibly with help of SIMD | 20:38.34 |
| | for starter, scaling sounds like a good start point, if you could give me some pointers to look at | 20:40.06 |
| Robin_Watts | liucougar: draw_simple_scale.c | 21:11.34 |
| | If you can identify hotspots using a profile (like say "Very Sleepy") then that would give you a good idea of where to start. | 21:12.04 |
| | I am not sure that there are a huge number of obvious hotspots though... | 21:12.16 |
| liucougar | Robin_Watts: thanks for the pointers | 21:51.50 |
| | Forward 1 day (to 2013/01/11)>>> | |
IRC Logs