| | <<<Back 1 day (to 2011/09/28) | 2011/09/29 |
| mvrhel2 | Robin_Watts: oh that is a good idea. we may do that this year | 00:19.21 |
| LaoLang_cool | hello, mupdf doesn't support continiously viewing, right? | 08:17.04 |
| kens | There is currently no support for viewing pages continuously in the viewer. | 08:17.32 |
| LaoLang_cool | kens, don't know if it's a todo in near future? | 08:18.24 |
| | It's not so convenient without it.. | 08:18.45 |
| kens | MuPDF is not the viewer, the viewer is built on MuPDF | 08:19.01 |
| | You could try SumatraPDF which uses MuPDF. | 08:19.11 |
| | Personally I don't like continuous viewing. | 08:19.24 |
| | PDF is, after all, a page based format | 08:19.47 |
| LaoLang_cool | kens, I got it, I'm using sumatraPDF, really nice | 08:20.39 |
| | kens, curiously, why don't you like continuous viewing? | 08:21.51 |
| kens | OK, well if you want continuous pages, tehn I'd ask the SumatraPDF folks. | 08:22.04 |
| | Basically you need to render 2 pages instead of one, and merge the page buffers. | 08:22.32 |
| LaoLang_cool | kens, sumartraPDF supports continuous paages | 08:22.33 |
| kens | Oh, right, well there you go then ;-) | 08:22.45 |
| LaoLang_cool | kens, oh, I misunderstood you.. | 08:23.19 |
| kens | As for continuous pages, I like to jump between. Like I said, PDF is a page based format. | 08:24.06 |
| LaoLang_cool | I don't understand what does 'shirk wrap' do? | 08:24.44 |
| kens | shirk wrap ? | 08:24.55 |
| LaoLang_cool | kens, sometimes a paragraph is broken into pages, then it's helpful to view two pages at the same time | 08:25.07 |
| | kens, in mupdf, there's a key shortcut w for shrink wrap | 08:25.30 |
| | I read it from the help of mupdf | 08:25.42 |
| kens | LaoLang_cool : 2 up is fine, I just don't like continuous | 08:25.54 |
| | I have no idea what shrink wrap is. | 08:26.02 |
| LaoLang_cool | but I don't understand what it does, I can't see the effect after I hit w | 08:26.06 |
| | kens, yes, 2 is fine, but mupdf supports only 1... | 08:26.25 |
| Dan_D_Mupdf | it resizes the window to contain the contents with no non-page space in it | 08:26.26 |
| kens | Thanks Dan_D_Mupdf :-) | 08:26.39 |
| LaoLang_cool | Dan_D_Mupdf, thanks! | 08:26.48 |
| Dan_D_Mupdf | well, i'm in the process of rebasing my mupdf branch on top of the current 0.9+ but it's annoying when I don't understand why a change was made | 08:28.03 |
| kens | You'll have to tackle tor8 about that, but there's usually a bug report to go with it, which may have some explanation. | 08:28.43 |
| | Not always though, the thread-safe work is an example. | 08:29.23 |
| LaoLang_cool | I find w doesn't work if a page is resized to a large scale, window can contain the page without extenting outside screen region | 08:30.41 |
| | even when scaled-up to 145dpi here, w won't work | 08:31.31 |
| Dan_D_Mupdf | yes there is a limit to the size of the window it's 90% of the screen width and height | 08:31.38 |
| LaoLang_cool | Dan_D_Mupdf, got it, thank you for explanation! | 08:32.09 |
| Dan_D_Mupdf | well, i've been a mupdf user/hacker since 0.2 | 08:32.34 |
| LaoLang_cool | wow, cool! | 08:32.55 |
| | Isn't pdf bookmark support render's business? mupdf hasn't any support on it | 08:33.40 |
| Robin_Watts | tor8: Morning | 10:52.49 |
| | Did you get anywhere with the try/catch stuff, or are you buried in other stuff? | 10:53.07 |
| tor8 | a little bit of both | 10:53.57 |
| | I did thread the context through for warnings as well. the code looks really ugly with that context being passed around :( | 10:54.42 |
| | and started out trying to try/catch stuff on the xps code | 10:54.55 |
| | didn't get very far on that yet | 10:55.23 |
| Robin_Watts | tor8: Yes, the context isn't nice, but it's better than any alternative I can think of, IMO. | 10:55.24 |
| tor8 | I'm going to try some performance tests with TLS when I get a chance | 10:55.55 |
| Robin_Watts | tor8: On every platform? | 10:56.15 |
| tor8 | on the major ones, ios, android, linux, macosx and windows | 10:56.43 |
| Robin_Watts | Knowing that TLS performs well enough on those doesn't tell us it will be OK on the next one (say WebOS) | 10:57.04 |
| tor8 | though I suspect ios/macosx will behave similarly with linux | 10:57.10 |
| | all the next ones will use linux at the core, I think that's a fairly safe bet these days | 10:57.33 |
| Robin_Watts | And the more you use TLS, the more like the context it becomes. | 10:57.56 |
| tor8 | the new blackberry tablet uses QNX I think | 10:58.02 |
| Robin_Watts | (If you need the TLS for mallocs and exception handling, then you need it in most functions. So you either pass it in to each function, or you do a function call in each function to get it. The former is cheaper in the long run.) | 10:58.50 |
| tor8 | I don't think you need it for mallocs | 11:00.23 |
| | and the latter, well, yeah | 11:01.02 |
| Robin_Watts | I think we need it for mallocs. | 11:01.13 |
| tor8 | system malloc doesn't ... why would we? | 11:01.35 |
| Robin_Watts | If I want to supply my own thread safe allocator, then I want to be able to pass in malloc/free/realloc function pointers, and an opaque void * to pass to them as an argument. | 11:02.23 |
| | That's what jpeglib and libpng do IIRC. | 11:02.59 |
| | You can argue that the function pointers can be hardwired, but the void * (if it's required) needs a context. | 11:03.32 |
| tor8 | unless the functions you point to use TLS inside ;) | 11:04.43 |
| Robin_Watts | I see the context as a small amount of unpleasantness that's ameliorated both by the amount of unpleasantness it saves elsewhere, and by the fact that it's consistent throughout the whole codebase. | 11:05.06 |
| tor8 | anyway, speculative feature. let's not implement that until we actually need it. | 11:05.19 |
| Robin_Watts | tor8: What? The void * is speculative ? | 11:05.36 |
| tor8 | and that's why we're doing this branch, to evaluate the context | 11:05.44 |
| | custom allocator | 11:05.52 |
| | I believe they were more common in the early 90's when libpng and libjpeg were first implemented | 11:06.29 |
| Robin_Watts | It's important in that it's something we are likely to need, and it'll make a major impact on the decision about which way to go with the context. | 11:06.35 |
| | But yes, that's why we're doing the branch :) | 11:06.46 |
| | OOh, really horrible idea. Let's make all of mupdf a C++ class, and 'this' can be the context. | 11:07.35 |
| | Shoot me now. | 11:07.38 |
| tor8 | *bang* I'd rather recode the whole thing in haskell | 11:08.00 |
| Robin_Watts | SMLNJ, please :) | 11:08.24 |
| | or orwell. | 11:08.27 |
| | Anyway, back to trying to understand clist code. | 11:08.55 |
| | chrisl: http://scottlinux.com/2011/03/05/ubuntu-11-04-change-from-unity-to-classic-gnome/ | 11:14.57 |
| | Allelujah! | 11:15.03 |
| tor8 | Robin_Watts, chrisl: follow in linus' footsteps and use Xfce instead | 11:16.54 |
| Robin_Watts | chrisl: You here? | 11:18.44 |
| chrisl | Yes, | 11:18.51 |
| | working on another computer...... | 11:18.58 |
| Robin_Watts | henrys mentioned adding memento targets to the unix makefiles. | 11:19.11 |
| | mind if I go ahead and do that? | 11:19.20 |
| | I need to get my head out of rops for a bit. | 11:19.27 |
| chrisl | Sure. Is it as a target or a configure option? | 11:19.41 |
| Robin_Watts | target. | 11:19.46 |
| chrisl | Good, that seems best to me | 11:19.55 |
| Robin_Watts | cool. | 11:20.02 |
| chrisl | I think I'll take an early lunch - OS X gives me a headache......... | 11:20.34 |
| ManDay | Excuse me, but why is mupdf so fckin retarted when it comes to scrolling? | 11:59.50 |
| kens | Polite questions are more likely to get answers | 12:00.19 |
| tor8 | good morning to you too | 12:00.22 |
| ManDay | yeah, good morning | 12:00.29 |
| Robin_Watts | is quite overcome with the urge to be helpful. | 12:00.40 |
| ManDay | well, you see, noramlly you scroll through a document, going from the end of one page to the start of the next... | 12:01.01 |
| kens | Oh we're back to continuous scrolling again | 12:01.30 |
| ManDay | mupdf does not only not automatically flip, it even does not over a method to go from the end of one page to the start of the next | 12:01.30 |
| | s/over/offer | 12:01.56 |
| Robin_Watts | ManDay: The "viewer" part of MuPDF is really just a simple example of how to use the core lib. | 12:02.25 |
| ManDay | seriously, what was the respective person actually *thinking* when he implemented that... | 12:02.29 |
| Robin_Watts | We have a better viewer in development, but it's far from ready for release. | 12:02.45 |
| ManDay | tor8's one? | 12:02.53 |
| tor8 | ManDay: try pgup/pgdn for flipping pages | 12:02.58 |
| kens | The respective person is here, I would urge you to be polite, you're much more likely to get a positive result | 12:02.59 |
| Robin_Watts | yes, tor8's one. | 12:03.12 |
| kens | And you cna always use SumatraPDF | 12:03.20 |
| tor8 | and it's actually spelled "retarded", two d:s | 12:03.21 |
| ManDay | I mean no offense to whoever did that part. It's just the thing itsself is retarded. | 12:03.49 |
| kens | Hmm, that's true tor8, two spelling mistakes in the same sentence. | 12:04.01 |
| ManDay | Thanks for the correction. | 12:04.03 |
| kens | ManDay if you don't mean to cause offence, tehn try to use less inflamatory language | 12:04.25 |
| Robin_Watts | The core lib is certainly capable of doing it (in fact it couldn't care). It's all down to how the viewer chooses to implement stuff. | 12:04.39 |
| ManDay | kens: But I AM inflamed! | 12:04.47 |
| Robin_Watts | SumatraPDF is an existence proof that it can be made to work. | 12:04.49 |
| ManDay | thanks tor8 , the pgup/down thing works, if you are at the end of a page | 12:05.02 |
| Robin_Watts | If you want to submit a patch that improves the viewer, we'll consider it. | 12:05.16 |
| tor8 | it's never bothered me enough, but then again I have been using 24" monitors for the past decade | 12:05.45 |
| ManDay | tor8: Have you by any chance looked into zathura? | 12:06.16 |
| tor8 | being incensed is reason to fix the program to your liking, not blowing your head off ;) | 12:06.18 |
| kens | As I said to somene else earlier, I dislike continuous scrolling of pages, I like flipping | 12:06.19 |
| ManDay | kens: I already implemented a patch for continous dragging btw | 12:06.55 |
| | i think your problem is the lack of threshhold (which makes you jump over the end of a page unknowingly), to which i can relate. i addressed that in the dragging part | 12:08.01 |
| kens | So I won't like your app ManDay, shall I complain ? ;-) | 12:08.40 |
| ManDay | what app? | 12:09.21 |
| tor8 | kens: he's talking about the poor man's continuous scrolling that mupdf has -- if you drag/pan the view along the edge far enough it'll flip pages for you | 12:09.30 |
| kens | THe one where you've implemented continuous scrolling | 12:09.38 |
| ManDay | if you dont like something, feel free to call it retarded as I did, just don't call ME so ;) | 12:09.40 |
| | kens: that app is mupdf | 12:09.47 |
| kens | Bo, its a fork at best since you patched it. | 12:09.58 |
| | No... | 12:10.03 |
| | And anyway, MuPDF is not the viewer | 12:10.12 |
| ManDay | no, it has been committed to master | 12:10.12 |
| | you know what i mean when I said mupdf | 12:10.23 |
| kens | :-) | 12:10.27 |
| tor8 | ManDay: you asked what I was thinking when I implemented the current behavior -- it's so the page remains centered on the same location for every page for when I've got a small window showing the whole page and I don't want to futz realigning it whenever I flip pages | 12:10.51 |
| ManDay | tor8: Good idea indeed | 12:11.07 |
| tor8 | the pgup/pgdn is there for when you don't want that | 12:11.20 |
| ManDay | Now that you mention it, that what positively surprised me when I first tried mupdf | 12:11.22 |
| | so the lack of "auto flipping" (by the same keys which scroll) was merely not done because you werent motivated, i see | 12:11.56 |
| tor8 | I think it was implemented at one time or another. these things have changed a lot over the years. | 12:12.19 |
| ManDay | tor8: Can you answer my quesiton? Just curious | 12:12.34 |
| Robin_Watts | A compromise idea might be to not change the position if the 'shrink wrap' region is all visible, and to scroll to the top/bottom of that window otherwise. | 12:13.25 |
| tor8 | which question? | 12:13.38 |
| Robin_Watts | tor8: "Excuse me, but why is mupdf so fckin retarted when it comes to scrolling?" ? :) | 12:14.18 |
| ManDay | no | 12:14.29 |
| tor8 | I just answered that one -- "because I like it that way" | 12:14.33 |
| ManDay | That one has adequately been answered :P | 12:14.38 |
| | I mean: | 12:14.41 |
| | tor8: Have you by any chance looked into zathura? | 12:14.48 |
| tor8 | ah. no, I haven't had time | 12:14.57 |
| | they didn't have any screenshots on their webpage, and I haven't got round to installing it | 12:15.20 |
| ManDay | tor8: whatch out when you do. make sure you get the girara based branch | 12:15.40 |
| | master will show you what it actually is, but girara is where it is heading | 12:15.57 |
| | ask mlq on #pwmt on oftc.net if you are interested | 12:16.11 |
| tor8 | and the debian package, what's that? | 12:16.23 |
| ManDay | master, i strongly assume | 12:16.37 |
| | girara is not stable or ready for production | 12:16.45 |
| | its a generic vimperator-like library | 12:16.54 |
| tor8 | okay | 12:19.19 |
| ManDay | (of course, it also allows GUI input, pwmt apps are GTK based) | 12:21.06 |
| Dan_D_Mupdf | i'm trying to update my patches to mupdf to 0.9+10 but i want to know what the code that the commit "Remove unused redraw timeout from X11 viewer" did as the same select statement is later added back in "Reload file in X11 viewer upon SIGHUP"; I review the changes so that i can git revert those i don't like such as the updated icon which looks terrible and any changes that add scrolling features such as the "flip pages when panning beyond threshold"; | 12:40.23 |
| | my main changes to mupdf was to clean up the usage of gapp in x11_main.c; "add o key to clone open pdf in new window"; "left hand paging keys s,d" (although i don't use these any more due to the following); "use xdg-open" (rather than "open" which is only available on OSX; although this should be platform...); reorder the title to put the page number first (comix does it the same way); paging with the mouse's scroll wheel; "do pdfapp_close after disco | 12:40.23 |
| | nnecting from X" (makes it seem that the window has closed sooner); cheat and call out to another program to write to the gtk clipboard; "set _NET_WM_PID on window"; "add options to pdfdraw to limit the output's width and height". then i have some unfinished work; the main one of interest is: the search hit cache which mantains an array the same size as the number of pages in each of it's cells is one of three values: hit, miss, unchecked. when search | 12:40.23 |
| | ing if you find a hit you mark the array otherwise you mark the miss and if the page your on is a miss you skip it when searching this makes doing `/ n N n N` really fast | 12:40.28 |
| tor8 | Dan_D_Mupdf: you'll have to ask sebras about the x11 viewer changes | 12:42.29 |
| sebras | Dan_D_Mupdf: I'm lurking here, but I'm at work so I can't really spend time explaining that here. is it ok if I leave you a message here later tonight? | 12:45.27 |
| Robin_Watts | chrisl_away: memento makefiles changes pushed. | 13:55.11 |
| | All test out OK for me here, but I can't test the ufst ones. | 13:55.23 |
| | Nothing I've done should have broken existing targets, so I figured it was safe to push them. | 13:55.38 |
| | bah. How long have these docs been out of date for ? | 14:02.05 |
| | since before records began, it seems. | 14:08.54 |
| kens | Which docs ? | 14:09.14 |
| Robin_Watts | file:///C:/CVS/artifex/ghostpdl.git/gs/doc/Drivers.htm <- the section on gx_strip_bitmap | 14:09.35 |
| kens | Oh,... | 14:09.43 |
| Robin_Watts | There hasn't been a 'strip_height' and 'strip_shift' since at least 1998. | 14:10.02 |
| | mvrhel2: Morning | 14:19.11 |
| kens | Well, my simple test file now works for everything except Tr 3 which messes up the currnt point for later drawing. | 14:31.46 |
| | And pdfwrite is eating the rectnagle that goes with the clip, but it always did that. | 14:32.05 |
| alexcher | marcosw_: I've opened a bug 692557 about "PNG from PDF" error. A fix will be available shortly. | 15:02.49 |
| marcosw_ | okay, thanks for letting me know. | 15:03.08 |
| alexcher | marcosw_: besides PDF interpreter error, the file has problems with masked image rendering. | 15:07.26 |
| marcosw_ | so you'll reassign it to mvrhel2 after you fix the PDF issue? | 15:09.23 |
| | btw, I added the customer number and upgraded it to P2. | 15:09.35 |
| alexcher | marcosw_: yes, I'll do this and attach a simplified sample file. | 15:10.41 |
| mvrhel2 | good morning | 15:26.52 |
| Robin_Watts | mvrhel2: I've just committed my first attempt at solving the planar texture problems. | 15:30.20 |
| | but it doesn't work for clist stuff, currently. | 15:30.30 |
| | Did my burblings from last night make any sense ? | 15:30.41 |
| mvrhel2 | Robin_Watts: well that is some good progress | 15:35.26 |
| Robin_Watts | Ah, excellent, ray_laptop too. | 15:35.44 |
| | as keeper-of-the-clist, this probably concerns him too. | 15:36.08 |
| mvrhel2 | Robin_Watts: so I am guessing that the cost for doing planar to chunky on the tile is probably pretty low due to the small size of it? | 15:38.07 |
| Robin_Watts | Well, it depends on the size of the tile :) | 15:38.25 |
| | but it's inelegant, certainly. | 15:38.36 |
| mvrhel2 | so there is no way (or is it very inefficient) just do keep the data in planar form? | 15:38.58 |
| Robin_Watts | I can write cores to do it, keeping it in planar form. | 15:39.21 |
| | At least for the common cases. | 15:39.25 |
| mvrhel2 | ok. | 15:39.34 |
| | that would make sense | 15:39.44 |
| Robin_Watts | But the problem that's currently occupying me is the clist case. | 15:40.03 |
| | The strip_copy_rop call is done with the tile data in the form of a gx_strip_bitmap | 15:41.54 |
| | typedef struct gx_strip_bitmap_s { | 15:42.42 |
| | byte *data; | 15:42.44 |
| | int raster; /* bytes per scan line */ | 15:42.46 |
| | gs_int_point size; /* width, height */ | 15:42.48 |
| | gx_bitmap_id id; | 15:42.49 |
| | ushort rep_width, rep_height; /* true size of tile */ | 15:42.51 |
| | ushort rep_shift; | 15:42.53 |
| | ushort shift; | 15:42.54 |
| | } gx_strip_bitmap; | 15:42.56 |
| | Effectively that just 'documents' a single plane. | 15:43.01 |
| mvrhel2 | oh. it is likely that you will need to add in a planar_count member | 15:43.25 |
| | just have it be -1 if it is chunky | 15:43.32 |
| Robin_Watts | Why -1? Why not 1? | 15:43.44 |
| mvrhel2 | and then you can get the size correct for writing and reading into the clist | 15:43.45 |
| Robin_Watts | Right. That's a public API change. | 15:44.01 |
| mvrhel2 | oh that would be fine too. | 15:44.08 |
| | -1 would just let me know it is not planar but chunky | 15:44.23 |
| | but I guess we don't need to know that for computing the size | 15:44.41 |
| Robin_Watts | Well, if we're making that change, I could avoid using the extra bit in the lop. | 15:45.09 |
| mvrhel2 | or, did I not put this someplace else in the pattern tile object | 15:45.16 |
| Robin_Watts | You have an 'is_planar' field in the tile. | 15:45.29 |
| mvrhel2 | I thought I did | 15:45.31 |
| | hold on | 15:45.45 |
| Robin_Watts | But it's not in the bit that gets passed through ere. | 15:45.48 |
| mvrhel2 | oh. yes. I originally tried to avoid the is_planar but there was some file that made me have to do it this way | 15:46.48 |
| ray_laptop | Robin_Watts: mvrhel2: sorry, I was clearing email. What's up (with the clist) ? | 15:47.45 |
| Robin_Watts | ray_laptop: We have to cope with passing planar gx_strip_bitmap's through the clist | 15:48.32 |
| ray_laptop | mvrhel2: I would think that 0 plane_count for chunky would be OK. | 15:49.03 |
| Robin_Watts | Why not 1? | 15:49.25 |
| | planar == chunky when plane_count=1 :) | 15:49.38 |
| | In fact the planar device silently drops back to chunky mode if you ask it for a 1 plane thing. | 15:50.19 |
| henrys | for debugging and readability it would be nice that they were different. | 15:50.32 |
| ray_laptop | Robin_Watts: is the planar data always all of the planes ? | 15:50.42 |
| Robin_Watts | Yes. | 15:50.49 |
| | Getting the information into the clist writer to tell it to write the larger information is no problem at all. | 15:51.23 |
| ray_laptop | so really you just need an 'is_planar' bool - you know how many planes, right ? | 15:51.24 |
| henrys | I had the idea that non-trivial rops could always use clist patterns not tiles, that gets rid of the colors but introduces new problems. | 15:51.49 |
| Robin_Watts | ray_laptop: You can get that information from the device, but it would be much easier to have it locally. | 15:52.16 |
| ray_laptop | henrys: yeah, like performance ! | 15:52.24 |
| | Robin_Watts: by 'that information' you mean the color_info.num_components ? | 15:52.51 |
| henrys | well non trivial rops should be rare if they weren't planar would probably be a really bad idea in general. | 15:53.10 |
| Robin_Watts | ray_laptop: Well... yes, I found myself wondering that earlier today. But all the existing code tends to work on 'num_planes' from the memory buffer device. | 15:53.46 |
| henrys | Robin_Watts:nonetheless it is a bug that has to be fixed:./pcl6 -dMaxPatternBitmap=10 -sDEVICE=plank -r300 -o foo.plk ~/Downloads/3656.bin; display foo.plk | 15:54.04 |
| Robin_Watts | The problem is that by the time we get to clist_change_tile, the thin thread holding my comprehension together snaps and everything drops on the floor in a mess. | 15:54.53 |
| | henrys: Sorry? | 15:55.01 |
| | I am aware that this example does not work in banded mode. | 15:55.24 |
| | That's the purpose of this discussion. | 15:55.32 |
| ray_laptop | henrys: did you open a bug report (that says what's wrong, and who is to work on it) ? | 15:55.36 |
| Robin_Watts | I wasn't suggesting we ignore it. | 15:55.40 |
| | ray_laptop: The example henrys just gave is exactly the example that is prompting this conversation. I am working on it :) | 15:56.16 |
| ray_laptop | Robin_Watts: I see. thanks for the clarification | 15:56.43 |
| Robin_Watts | I am trying to decide if expanding the struct is actually required. | 15:57.39 |
| henrys | What the example shows is that there is different output depending on if clist patterns are used vs. non-clist patterns. This is different than the problems I see with regular banding. | 15:57.44 |
| | that is MaxPatternBitmap not MaxBitmap | 15:58.26 |
| Robin_Watts | Oh, sorry, hadn't twigged that. | 15:58.38 |
| | Well, I'll worry about that after I get MaxBitmap working :( | 15:58.53 |
| | It may be the same fix will fix both? | 15:59.13 |
| | (please don't crush my hope) | 15:59.21 |
| | I can probably get to clist_change_tile with an extra int that says how many planes there are. | 16:00.24 |
| henrys | I was thinking it would be best to do non trivial rops with the clist patterns that will bypass completely what you are currently struggling with but I haven't studied it. | 16:01.49 |
| | the appearance of the differences look like very different problems to me. | 16:02.10 |
| | clist vs clist-patterns | 16:02.18 |
| Robin_Watts | but I don't know the clist writing code well enough (i.e. at all) to know whether I can futz the cmd_put_bits call to tell it to write a bitmap that's 'n' times as tall without that altering the parameters that will be in the gx_strip_bitmap header on reading back. | 16:02.53 |
| kens | is logging off now, enjoy the rest of your day. | 16:03.26 |
| Robin_Watts | henrys: AIUI, the pattern I have now is from a halftone. Not sure that that can be done as a clist pattern. | 16:03.29 |
| henrys | well it was halftoned I hope becuase the device was the pattern accumulator which had debth 4. | 16:04.48 |
| ray_laptop | Robin_Watts: so the amount of data to be written is different because the planar data has different padding than the chunky data, right ? | 16:05.03 |
| henrys | what if the pattern were larget the MaxPatternBitmap? the code fails. | 16:05.17 |
| Robin_Watts | henrys: I'm suffering multitasking failure here. | 16:05.46 |
| henrys | s/larget the/larger than | 16:06.10 |
| ray_laptop | is still on first cup of coffee and having trouble following what's the problem here | 16:06.14 |
| Robin_Watts | Can we shelve the MaxPatternBitmap stuff for a mo, please? | 16:06.16 |
| ray_laptop | I think that would help me, too | 16:06.33 |
| Robin_Watts | ray_laptop: The gx_strip_bitmap header is set up to point to the first planes data. | 16:06.52 |
| ray_laptop | Robin_Watts: right, with the *data member ? | 16:07.19 |
| Robin_Watts | hence data, raster, width, height all give exactly the first planes worth of data. | 16:07.28 |
| henrys | sort of I just think the proper way to do patterns with non trivial rops is to use the pattern clist and anything else seems doomed but continue. | 16:07.36 |
| Robin_Watts | So currently the clist writes just the first plane into the clist. | 16:07.42 |
| | What it *should* do, is in the case of planar data, write num_planes times as much data. | 16:08.33 |
| | (i.e. the 2nd, 3rd and 4th planes follow immediately after the 1st one) | 16:09.00 |
| | So I could probably futz the system into doing the right thing by multiplying the height on entry to cmd_put_bits by num_planes. | 16:09.33 |
| ray_laptop | Robin_Watts: in chunky mode, the *data area is more than a single plane (e.g. in 4-bit depth, it is 4-bits per pixel) in planar mode it is (roughly) the same amount of data (4 1-bit planes) | 16:10.08 |
| Robin_Watts | ray_laptop: Right. | 16:10.20 |
| | raster is smaller for plane data than chunky data. | 16:10.32 |
| ray_laptop | but there is a raster (causing line end padding) that will make the 4 1-bit planes larger. | 16:11.24 |
| Robin_Watts | cmd_put_bits basically encodes raster*height bytes worth of bitmap data, right? | 16:11.39 |
| ray_laptop | Robin_Watts: there is also 'width_bits' | 16:13.16 |
| | cmd_put_bits is rather a mess (short_raster, full_raster, optional compression and all of that) | 16:15.00 |
| ray_laptop | can make that comment since I didn't write it ;-) | 16:15.25 |
| Robin_Watts | can safely agree then :) | 16:15.35 |
| ray_laptop | Robin_Watts: so the problem is telling cmd_put_bits that the data is planar ? | 16:16.36 |
| Robin_Watts | Maybe. | 16:18.18 |
| | I think I have a vague roadmap now. | 16:18.32 |
| | I'll update gx_strip_bitmap with a num_planes thing. | 16:19.03 |
| | Then we can send that. | 16:19.08 |
| | Then if that's set to some >1 value, I can change the call to cmd_put_bits so that it's encoding the right thing. | 16:19.34 |
| | Then I have to change the clist reader. | 16:19.41 |
| | Wow. Say it fast and it sounds easy. | 16:19.51 |
| | OK. This is clist, the chinatown of ghostscript, so be prepared for me asking for help :( | 16:20.19 |
| ray_laptop | Robin_Watts: yes, it does (sort of like swallowing bad tasting medicine quickly) | 16:20.23 |
| Robin_Watts | OK, so now back to henrys, I think... who can try to convince me that I don't need to do any of that at all... | 16:21.14 |
| ray_laptop | Robin_Watts: I'll check here on IRC frequently. If I'm not paying attention, you can ask henry or mvrhel or someone to call me (to wake me up) | 16:21.23 |
| Robin_Watts | ray_laptop: Thanks. | 16:21.33 |
| ray_laptop | IMHO, the performance hit of pattern-clist is a killer if we don't have to. | 16:21.59 |
| | if it's a small tile filling a large area, we could be re-interpreting the pattern clist a BUNCH of times | 16:22.57 |
| Robin_Watts | henrys: So with pattern clist you're seeing "blocked out text"? | 16:23.41 |
| henrys | right. | 16:24.15 |
| ray_laptop | even with big patterns the pattern-clist is 2x worse than doing the tile. (timed with -dMaxPatternBitmap=200000000 and the file from Bug691652) | 16:24.33 |
| Robin_Watts | I have absolutely no idea what's going on there. | 16:24.33 |
| | That sounds like another thing I need to dig through the code to understand. | 16:25.13 |
| henrys | ray_laptop:I think there something broken with pattern-clist it shouldn't be as slow as it is. | 16:25.20 |
| Robin_Watts | My instinct is that ray_laptop is right. | 16:25.31 |
| | If we rely on pattern clist, it'll be painfully slow. | 16:25.47 |
| | Especially as we are (I think) fairly close to having this work now. | 16:26.02 |
| ray_laptop | henrys: I'll do a profile of Bug691652 PS file and see if anything bubbles up | 16:26.13 |
| henrys | it doesn't matter we have to support both. | 16:26.18 |
| Robin_Watts | henrys: Well, you were (I thought) advocating the idea of just supporting pattern clist. | 16:26.59 |
| ray_laptop | maybe I convinced him ;-) | 16:27.19 |
| Robin_Watts | And then I wouldn't need to do the banded case because it'd never be used. | 16:27.19 |
| | IF you've dropped that idea, then yes, I agree, we need to do both. | 16:27.37 |
| henrys | I'm not speaking right ... if you go your route it doesn't save us from fixing the bug because a large pattern will trigger the problem. | 16:27.48 |
| Robin_Watts | Absolutely, yes. | 16:28.01 |
| henrys | I was thinking more importantly with the clist would the pattern rop be done in halftoned space? Or would it be done before halftoning? | 16:28.41 |
| Robin_Watts | But the only case in which it would make sense to drop this and go digging into pattern clist now would be if we believe that there was a possibility that I might not have to finish this code. | 16:29.00 |
| ray_laptop | Robin_Watts: Just think of filling the background of a page with a 2x2 pixel tile | 16:29.40 |
| Robin_Watts | ray_laptop: Oh, I understand that. | 16:29.52 |
| | I don't believe that there is a possibility that I won't have to finish this code. Hence I'd like to do that first. | 16:30.09 |
| ray_laptop | agrees with Robin_Watts | 16:30.36 |
| Robin_Watts | henrys: My head is still spinning from that question. | 16:31.14 |
| | But the magic 8 ball that is my brain is settling slowly... | 16:32.16 |
| | Why would the fact it's a pattern clist change the place the pattern rop is done ? | 16:32.43 |
| | I don't know enough to answer that question. | 16:33.59 |
| henrys | well you are rasterizing the pattern to the pattern cache which maybe 1 bit gray not even cmyk I am not sure where the rop is done with the clist. | 16:34.37 |
| | patterns | 16:34.42 |
| Robin_Watts | Currently, in the non-clist pattern case, we rasterise the pattern into a planar buffer. | 16:35.53 |
| | Then that buffer gets played out and ropped. | 16:36.03 |
| henrys | Robin_Watts:okay so the operation with the source is done after it is rendered to planar? | 16:37.04 |
| Robin_Watts | Yes, that's the problem. | 16:37.36 |
| | 'T' is already rendered into planar format, and strip_copy_rop has never understood T in planar format. | 16:38.22 |
| henrys | okay then in theory there should be no advantage to the clist-patterns and the problems we are seeing is just a bug. | 16:38.41 |
| | for some reason I thought you had the original color for source and pattern but not destination. sorry I've confused everyone. | 16:39.29 |
| Robin_Watts | In the clist pattern case, I'd assume that the rasterisation that would have happened into the planar pattern buffer now happens repeatedly into the destination buffer. | 16:39.38 |
| | This is confusing stuff. | 16:40.13 |
| | Not helped by HP's docs using pattern and texture interchangably. | 16:40.33 |
| marcosw_ | Robin_Watts: I have a simple question about Visual Studio: once I've built the Ghostscript project I do I run gs in the debugger? | 16:43.23 |
| Robin_Watts | marcosw_: See gs/win32/ReadMe.txt :) | 16:43.46 |
| | marcosw_: See win32/ReadMe.txt :) | 16:43.57 |
| marcosw_ | cool. thx. | 16:44.47 |
| Robin_Watts | np. | 16:44.50 |
| | It's annoying that you can't preset that in VS. | 16:45.11 |
| | but it goes in user specific files. | 16:45.22 |
| mvrhel2 | whew. I think I have these overprinting issues put to bed. hopefully the clusterpush will come back good. | 16:51.23 |
| | then I will be a zero customer bugs finally | 16:51.30 |
| | henrys: I will start looking at the xps issues now | 16:51.43 |
| henrys | wow mvrhel2 nice. | 16:53.57 |
| Robin_Watts | Was there a consensus on whether I should use num_planes = -1 ? or 0 or 1 ? | 16:59.01 |
| | 1 wins for me, as otherwise I have to do (num_planes <= 1 ? 1 : num_planes) everywhere I want to use it. | 16:59.48 |
| mvrhel2 | Robin_Watts: I am fine with 1 | 17:00.06 |
| | whatever makes your life easier | 17:00.23 |
| | and makes the code clean and easy | 17:00.31 |
| | to understand | 17:00.41 |
| henrys | Robin_Watts:does memento support both ialloc.c and gsmchunk.c or just ialloc? - you said it put each allocation in a separate chunk - I assume that meant ialloc.c. | 17:06.06 |
| Robin_Watts | chunk too. | 17:09.05 |
| | gsalloc.c and gsmchunk.c both have #ifdef MEMENTO in them. | 17:09.43 |
| henrys | right thanks | 17:12.34 |
| Robin_Watts | henrys: I can't claim it's been extensively tested, but it seemed to work. | 17:12.54 |
| mvrhel2 | Robin_Watts: does your commit to bmpcmp get clustertested? | 17:17.56 |
| Robin_Watts | I don't know. | 17:34.08 |
| | I'd hope not. | 17:34.15 |
| | but your job will go first. | 17:34.20 |
| | user jobs trump git jobs. | 17:34.35 |
| mvrhel2 | yes. but I want to run a bmpcmp after this one finishes | 17:37.43 |
| | I think yours will start before then | 17:37.48 |
| | but hopefully not | 17:37.55 |
| Robin_Watts | Yes, mine will get the chance to run, but I'd hope it will take zero time. | 17:38.29 |
| mvrhel2 | I think I have to wait until my current run finishes before submitting yes? | 17:38.29 |
| Robin_Watts | mvrhel2: You never had to before, but then marcosw changed it. He may have changed it back. | 17:38.55 |
| mvrhel2 | ok. well yours stopped. so no worries | 17:39.23 |
| Robin_Watts | For future reference, instead of doing: git cluster pcl then git cluster bmpcmp, you can just do: "git cluster bmpcmp pcl" | 17:39.39 |
| | That runs the pcl tests, then bmpcmps it. | 17:39.51 |
| | Or "git cluster bmpcmp gs xps pcl ls" for the whole lot. | 17:40.10 |
| mvrhel2 | oh | 17:41.02 |
| | wow | 17:41.09 |
| | ok. that fixes overprinting for now | 17:57.45 |
| Robin_Watts | congrats. | 17:57.51 |
| mvrhel2 | until the next bug trickles in.... | 17:58.03 |
| Robin_Watts | mvrhel2: Did you report the lcms v2 thing to marti? | 17:58.38 |
| mvrhel2 | ah. I still need to build his tools to make sure I can create with them. To do that I need to pull in libtiff or something. I will fool with that this week | 17:59.43 |
| Robin_Watts | It's going to become more urgent when the new ubuntu comes out, cos tkamppeter is dogmatically going to ship gs using a shared lcms2, despite chrisl and I warning him against it. | 18:00.47 |
| mvrhel2 | when is that going to occur? | 18:01.01 |
| Robin_Watts | Final ubuntu release is any day I believe. | 18:01.19 |
| mvrhel2 | oh | 18:02.01 |
| chrisl | Do we have any feel for how common the problem with lcms2 is likely to be? | 18:02.05 |
| Robin_Watts | I don't; I know there is at least one test file (one constructed my mvrhel2) that shows it. | 18:02.28 |
| mvrhel2 | not very common. I don't know anyone who is using those new ICC elements | 18:02.43 |
| | I had to construct an example since there are none to be found | 18:03.01 |
| chrisl | Well, it's probably not desperately urgent then, but it would be good to get it resolved, so *we* can make the move | 18:03.38 |
| Robin_Watts | We've done speed updates to lcms1 too, I believe. | 18:04.43 |
| | So we can start to port them over to lcms2 when the rest of it works. | 18:05.02 |
| mvrhel2 | yes. | 18:05.08 |
| | bbiab | 18:12.27 |
| tkamppeter | Robin_Watts, mvrhel2, Ubuntu Oneiric (Final Freeze today, release in two weeks) will come with GS 9.04 and using the old liblcms (1) as shared lib. I personally would use the built-in libs, but the other developers of Debian and Ubuntu do not accept this. | 18:12.53 |
| mvrhel2 | oh that will be interesting. | 18:13.40 |
| | we have def. fixed issues in lcms1.8 | 18:13.49 |
| tkamppeter | Robin_Watts, mvrhel2, plans for Ubuntu 12.04 (release end of April 2012) are GS 9.05 with shared liblcms2. | 18:13.49 |
| Robin_Watts | tkamppeter: Well, all I can say is that chrisl's warning stands. We won't accept bug reports raised against gs if people are not using our supplied lcms1. | 18:14.37 |
| mvrhel2 | bbiaw | 18:15.17 |
| Robin_Watts | If you're determined to use a shared lib, then it may make sense to take our lcms1 as the shared lib rather than the stock one. | 18:16.19 |
| | Especially given that lcms1 is not being developed any more. | 18:16.30 |
| henrys | tkamppeter will have to fork the code, shared lcms shouldn't even be allowed in our released configurations. | 18:23.12 |
| | I think it is forced to static now. | 18:24.04 |
| Robin_Watts | henrys: In 9.04 it's allowed. In 9.05 it won't be (unless we are moved over to stock v2 by then). | 18:25.21 |
| | henrys: I added the Memento targets for you earlier. I haven't tested the ufst-memento ones. | 18:26.31 |
| henrys | thanks | 18:26.47 |
| Robin_Watts | ray_laptop: Would you object to me changing cmd_depth_to_code ? | 18:50.36 |
| | AFAICT, we need to cope with input values (depth) = 1,2,4,8,12,16,24,32,40,48,56,64 | 18:51.46 |
| ray_laptop | Robin_Watts: no problem. | 18:51.47 |
| Robin_Watts | so 12 possible values. Using 5 bits for that seems excessive. | 18:52.12 |
| | especially when I want one of those bits for myself. Muhahah. | 18:52.24 |
| ray_laptop | Robin_Watts: I don't know if 12 works now, | 18:52.40 |
| Robin_Watts | Well, my new encoding copes with 12, so that's fine. | 18:53.00 |
| | as long as we don't need 11 or 14 or anything :) | 18:53.19 |
| ray_laptop | Robin_Watts: thanks for explaining your ulterior motive | 18:53.21 |
| | Robin_Watts: and I can trust you to put in decent comments | 18:54.48 |
| Robin_Watts | sure. | 18:55.17 |
| ray_laptop | that wasn't true for some of the folks that hacked around in the clist code -- take a look at all of the "magic numbers" in the compositor queue stuff (but not on a full stomach) | 18:56.20 |
| | but that was before it landed back in my lap. | 18:57.18 |
| henrys | I completely spaced out the meeting guess we didn't need one - nobody else said anything unless I missed it. | 19:05.26 |
| ray_laptop | henrys: I had a meeting with myself ;-) | 19:05.49 |
| | but I didn't review the bugs -- the agenda was too full ;-) | 19:06.15 |
| tkamppeter | henrys, Robin_Watts, what are the exact problems of the shared LCMS1? Segfaults like this known one on Apple-generated EPS figures or also color accuracy? | 19:10.44 |
| Robin_Watts | both, yes. | 19:11.09 |
| | ooh, that's confused me. | 19:13.03 |
| | We write into the clist from a gx_strip_bitmap | 19:13.13 |
| | and we read back into something completely different. | 19:13.23 |
| marcosw_ | mvrhel2: I was worried that you didn't have any customer bugs so I found a couple and have assigned them to you :-) | 19:17.41 |
| henrys | tkamppeter:I think the best policy for you is to only use shared a shared library if our autoconf allows it. | 19:20.37 |
| Robin_Watts | henrys: Sadly 9.04 allows shared lcms1 or 2. | 19:22.58 |
| henrys | I think the best policy for future ghostscript release is to ... ;-) | 19:23.54 |
| Robin_Watts | releases the code to the cluster and runs away for dinner. | 19:35.37 |
| tkamppeter | henrys, OK, so I will early in the cycle for Ubuntu 12.04 switch to lcms2 shared to be prepared for GS 9.05. | 20:02.38 |
| henrys | lcms should be static until our changes have been excepted and integrated upstream. At that time chrisl will make autoconf allow lcms to be shareable. It should not been shared in 9.04 | 20:06.01 |
| | s/excepted/accepted | 20:06.11 |
| | tkamppeter:chris will make it available as a shared object in the configuration if gs will produce correct results with it, I don't see what else we can do. | 20:17.19 |
| | Forward 1 day (to 2011/09/30)>>> | |
IRC Logs