| | <<<Back 1 day (to 2011/07/22) | 2011/07/23 |
| Robin_Watts | hey ghostgum | 00:04.32 |
| | Damn. In case he comes back later and reads logs; do you have thoughts on my patch on bug 692235? | 00:05.48 |
| mvrhel2 | ok. looks like composite black has become K only | 00:16.51 |
| | henrys: check out the bmpcmp results | 00:17.12 |
| | firefox crash... | 00:35.41 |
| henrys | the changes look like just what we want. | 00:36.46 |
| | only 273 pages of changes ;-^ is that like the bmcmp max? | 00:39.33 |
| mvrhel2 | ok. a regression in the bmpcmp that I need to track down. I bet this is occurring with transparency | 00:45.44 |
| | dinnertime now | 00:45.50 |
| Robin_Watts | hey kens | 09:34.29 |
| | I got the mkromfs changes working to compact the postscript files before going into %rom% | 09:35.09 |
| | and it saves 640K. | 09:35.15 |
| | But... when I clusterpush, I get 4379 problems, all in ps2write. | 09:35.35 |
| ghostgum | Who is Shailesh? | 09:35.56 |
| Robin_Watts | ghostgum: Hi. | 09:36.04 |
| ghostgum | Hi Robin | 09:36.18 |
| Robin_Watts | Shailesh is a friend of kens/chrisl, who is doing some contract work for us. | 09:36.20 |
| | He's soing a bug scrub; running through all the bugs checking which ones have been fixed. | 09:36.47 |
| | The theory was we might have fixed a lot without realising. | 09:37.02 |
| ghostgum | I see from an IRC discussion attached to a bug report, that we are still battling with work arounds for GS now handling multiple instances and dodges for memory leaks. | 09:37.09 |
| | s/now handling/not handling/ | 09:37.31 |
| Robin_Watts | The lib_ctx pointer stuff ? | 09:37.32 |
| ghostgum | Yes | 09:37.36 |
| Robin_Watts | I think that they've found the 'right way' to fix it (move it out of the gc'd domain). | 09:38.11 |
| | Did you see my patch on bug 692235 ? | 09:38.30 |
| ghostgum | looking now | 09:38.43 |
| | From your description, it will result in something similar to how the 256-bit display device used to work. | 09:39.55 |
| | Video cards for the last 10 years have defaults to 24-bit or better, so that mode doesn't get much use. | 09:41.29 |
| Robin_Watts | Was there a reason we used the 96 colour one? | 09:43.56 |
| | Was that a palette you invented, or was it somehow a 'standard' one ? | 09:44.14 |
| ghostgum | It was something I invented. It gave reasonable results for 8-bit colour (which was already a little used mode), but without having to deal with a variable pallete. | 09:45.06 |
| Robin_Watts | Right. So any objections to my patch going in then ? | 09:45.41 |
| ghostgum | For colours set by setrgbcolor, it would use the 64 colour 4x4x4 palette. For colours set by setgray, it would use the 32-level greys, so it would anti-alias for greyscale but not for colour. | 09:46.08 |
| | Given that the previous behaviour has been broken, no objections to your patch which (I haven't looked at your code) will probably make the display 8-bit mode behave closer to the original behaviour. It should perhaps be tested with 8-bit image formats, but I don't know that any of those used the same trick as the display device to make colour cube and grey scale have a different number of levels. | 09:48.04 |
| Robin_Watts | What do you mean by "tested with 8-bit image formats" ? | 09:49.04 |
| | presumably you mean 'input' formats, because this only affects the display device, right ? | 09:49.24 |
| ghostgum | png256 etc. But I don't think it behaved the same as display in 8-bit native. | 09:49.52 |
| Robin_Watts | AIUI, 8 bit pngs are variable paletted. | 09:50.31 |
| | so if you want to go to a fixed paletted display, the best you can do is to make sure the fixed palette has reasonable coverage, and a 6x6x6 cube is pretty much the best you can do. | 09:51.10 |
| | (with the extra greys as a bonus) | 09:51.42 |
| ghostgum | What we used to have with display 8-bit native was half toning of colours, and 32-level greys without half toning. | 09:52.03 |
| | png256 used gdevpccm.c for colours, which is a larger fixed palette. It doesn't have enough grey levels to anti-alias them. I don't think I messed with the palette for those. So display 8-bit native is probably unique, which it means it gets broken because nobody uses it. | 09:54.42 |
| Robin_Watts | http://ghostscript.com/~robin/colcir8.png | 09:56.31 |
| | That's halftoned in the colours, and not in the greys. | 09:57.25 |
| | gdevpccm.c uses a 6x6x6 cube. | 10:03.31 |
| | 8 bit display device now uses 6x6x6 + 40 greys. | 10:03.46 |
| | So we get the best of both worlds. | 10:04.06 |
| ghostgum | Your colcir8.png looks how I expect it to look. | 10:04.09 |
| Robin_Watts | cool. | 10:04.13 |
| ghostgum | Did you change the display 8-bit native device palette? | 10:04.29 |
| Robin_Watts | I changed everywhere I could find that 8bit 96 color palette. | 10:05.00 |
| | If I've missed somewhere, please say. | 10:05.09 |
| ghostgum | Is it still a 96 colour palette? | 10:05.15 |
| Robin_Watts | No. It's now a 256 color palette. | 10:05.29 |
| ghostgum | Have you tried it with GSview? In GSview, select "Media, Display Settings, Depth, 8". I suspect it is going to break that mode in GSview. | 10:20.18 |
| | Yes, it will break. The palette is not passed from the display device, so GSview assumes the previous 96 colour palette. | 10:22.42 |
| | So either your code gets changed to use the old palette, or I change GSview to use the new palette if GS version > 9.03. | 10:28.13 |
| | Last time I made an imcompatible change by adding separations, I changed the display structure version number. | 10:29.16 |
| Robin_Watts | ghostgum: sorry, was running. | 12:03.59 |
| | how hard is it to change gsview if gs > 9.03 ? | 12:04.17 |
| | or I can change the display structure version number if that's better (and you point me at the bit to change) | 12:20.15 |
| mvrhel2 | Robin_Watts: are you there? | 14:38.00 |
| Robin_Watts | I am. | 15:30.39 |
| | mvrhel2: ^ | 15:30.50 |
| mvrhel2 | So I am wondering if your fix with the dirty rects fixes 692249 | 15:48.33 |
| | Robin_Watts: ^^ | 15:48.54 |
| Robin_Watts | hi. let me look at the bug. | 15:49.51 |
| | I just closed bug 692235 btw. | 15:50.29 |
| | Still seems slow. | 15:53.48 |
| | From my memory when I looked at this stuff, it was doing a function call per pixel (possibly more than one function call per pixel). | 15:54.21 |
| | I was wondering about refactoring the code into using function pointers, so that we could optimise the common cases. | 15:55.01 |
| | Feel free to assign it to me, as an enhancement bug and I can investigate it when I get time. | 15:56.15 |
| mvrhel2 | ok. I was just wondering. | 15:57.28 |
| ray_laptop | Robin_Watts: can you send me a patch for your mkromfs improvements ? | 19:45.34 |
| | Robin_Watts: also, I didn't understand the comment about "I should look at converting hex numbers to decimal, and hex strings to binary." | 19:46.20 |
| | representing the 'begincidrange' strings (that are now hex) with of CMaps as 16-bit binary would be good, but I don't follow how converting hex numbers to decimal helps. | 19:49.53 |
| | in order to change the begincidrange to 3 16-bit binary numbers, we'd either have to change the way the operator works to detect binary and load the expected stuff on to the stack up to the 'endcidrange' | 19:56.17 |
| | or change the CMap files to use a different operator. | 19:56.57 |
| | That's the common case, and we could similarly hand begincodespacerange and beginbfchar to use 16-bit binary numbers | 20:02.25 |
| | The beginbfchar is a little tricky since the strings may be longer than 4 hex digits in some cases e.g. Adobe-Japan1-UCS2 | 20:05.51 |
| | I wouldn't recommend that we do this before the 9.04 release ! | 20:06.09 |
| | hmm... and CNS-EUC-H seems to have 32-bit values in begincidrange triplets | 20:09.29 |
| | and 90pv-RKSJ-UCS2 has 64-bit numbers and Adobe-Japan1-UCS2 has 128-bit !!! | 20:15.19 |
| | they are not as common, but we'd have to allow for them | 20:19.16 |
| | I'll take a crack at this when I get past cust 532 and release critical issues | 20:35.51 |
| ghostgum | Robin: my preferred solution would be to make the display device work with the previous 96 entry palette. I do not expect that many people use that mode. | 22:17.11 |
| Robin_Watts | ray_laptop: Sure. | 22:43.45 |
| | ray_laptop: Lots of the files have 16#fefc or something. | 22:44.04 |
| | which can be represented more efficiently as 65504 (or whatever it is) | 22:44.29 |
| | The hex strings to binary is something that I saw in your code, but don't fully understand. | 22:45.15 |
| | ray_laptop: http://ghostscript.com/~robin/0001-mkromfs.patch | 22:47.08 |
| | Forward 1 day (to 2011/07/24)>>> | |
IRC Logs
