| | <<<Back 1 day (to 2012/03/09) | 2012/03/10 |
| Robin_Watts | mvrhel: Ping? | 00:11.52 |
| | Hey? I'm very confused. I did NOT push the HPGL path handling to the main repo. | 00:14.48 |
| | $ git logg -20 | 00:15.10 |
| | * e666e1e (HEAD, master) Support HPGL style path handling. | 00:15.12 |
| | * 91b362b (origin/master, origin/HEAD) Fix typo in last commit that stopped Memento builds working. | 00:15.14 |
| | * c66ce76 Updated Memento pulled in from mupdf. Plus nesting fixes. | 00:15.15 |
| sebras | Robin_Watts: openjpeg 1.5.0 broke my linux-build... | 00:18.09 |
| Robin_Watts | sebras: Everything else I've touched today has broken, so why not that too :( | 00:18.43 |
| | sebras: What's the error? | 00:18.59 |
| sebras | Robin_Watts: No rule to make target `build/debug/opj_cidx_manager.o', needed by `build/debug/libopenjpeg.a'. | 00:19.18 |
| | I guess this is something in Makethird, but I never delved into that file... | 00:21.05 |
| | oh... | 00:21.28 |
| | ?-) | 00:21.33 |
| Robin_Watts | Do you still have openjpeg-1.4 in your thirdparty dir? | 00:22.47 |
| | Cos it finds the files by using a wildcard search, and that will confuse it, I suspect. | 00:23.21 |
| sebras | of course. | 00:23.23 |
| | yes, it did. but unzipping the new thirdparty give complaints about the lack of freetype2... | 00:23.59 |
| Robin_Watts | Eh? | 00:24.16 |
| sebras | argh! ignore me... | 00:24.23 |
| Robin_Watts | seems to have infected sebras :) | 00:24.40 |
| sebras | there, sorry for the noise. :) | 00:25.23 |
| | argh! ignore me... | 00:30.00 |
| mvrhel | oh Robin_Watts | 00:31.08 |
| | you still up? | 00:31.12 |
| Robin_Watts | Just about. | 00:31.17 |
| mvrhel | hehe | 00:31.26 |
| | ok one quick question | 00:31.29 |
| | so I see that the planar device allocates a regular memory buffer and then uses a clever set of pointers to get to the data | 00:32.13 |
| | but I have an issue | 00:32.22 |
| | I am running a simple case where I have 9 components which means the depth in color info is 72 | 00:32.45 |
| | and there are no memory prototypes for such a size | 00:32.57 |
| | I am trying to think of the best way to do this with out reeginnering the whole planar stuff | 00:33.47 |
| Robin_Watts | If I remember correctly the standard memory layout for a planar block of w*h*n pixels is span*h*n bytes. | 00:34.06 |
| | where span is w rounded up to some alignment (8 bytes by default I think). | 00:34.30 |
| | BUT it's possible to use other layouts. | 00:34.39 |
| mvrhel | ok. is the memproto type (e.g. mem32 mem64 etc) used just to allocate the space | 00:35.27 |
| Robin_Watts | The default stuff effectively has h lines of C followed by h lines of M followed by h lines of Y etc. | 00:35.33 |
| | But it's possible to use other layouts. | 00:35.42 |
| mvrhel | i.e. is there any reason I can't use a different one just make sure that the size is suffficient? | 00:35.46 |
| Robin_Watts | The plib device allocates all it's own space. | 00:36.07 |
| mvrhel | hmmm | 00:36.13 |
| Robin_Watts | and it has line pointers set up so that we get 1 line of C, then 1 line of M then 1 line of Y then 1 line of Y, then back to C again. | 00:36.33 |
| mvrhel | hold on | 00:36.40 |
| | let me point you to where I am getting confuse | 00:36.48 |
| | d | 00:36.50 |
| Robin_Watts | OK. This is dredging my memory here, so it'll take me a while to get back up to spee.d | 00:37.12 |
| mvrhel | in gdevppla.c | 00:37.56 |
| | line 118 | 00:38.01 |
| | hold on | 00:38.30 |
| Robin_Watts | yeah, just nosing around there myself. | 00:38.46 |
| mvrhel | actually line 113 | 00:39.07 |
| | this heads in to gdevprn.c | 00:39.25 |
| Robin_Watts | Line 113 is blank for me. | 00:39.33 |
| | gx_default_create_buf_device ? | 00:39.43 |
| mvrhel | yes | 00:39.47 |
| | so that function | 00:40.03 |
| | it gets a prototype based upon the depth | 00:40.15 |
| Robin_Watts | I believe plane_index = -1 for this case, right? | 00:40.30 |
| mvrhel | which for me is 72 with my 9 components | 00:40.30 |
| | yes | 00:41.13 |
| | and so it fails to get mdproto | 00:41.26 |
| | and ends at that | 00:41.34 |
| Robin_Watts | OK. So as you say, it gets a memory device for that number of bits. | 00:41.39 |
| | but why... | 00:41.42 |
| mvrhel | are you asking me? | 00:42.05 |
| | or is that a rhetorical question | 00:42.19 |
| Robin_Watts | I'm thinking. | 00:43.12 |
| mvrhel | I am sorry. I know its late | 00:43.25 |
| Robin_Watts | gs_make_mem_device uses mdproto just to be able to call gx_device_init | 00:44.11 |
| mvrhel | ok so let me fake it out so I get something and push on for a sec | 00:44.43 |
| Robin_Watts | ah, it's worse that that. | 00:44.56 |
| mvrhel | now I am at line 1047.... | 00:45.06 |
| | gs_make_mem_device | 00:45.11 |
| Robin_Watts | when it does the init it copies lots of things from mdproto into the new device, so we are going to need to give it a new device. | 00:45.38 |
| mvrhel | which inits a bunch of stuf | 00:45.41 |
| Robin_Watts | I suspect we need to make 'get_mem_device_for_bits' return a general 'larger than 64' prototype. | 00:46.16 |
| mvrhel | yes | 00:46.29 |
| | so when are where are the planar buffers created? | 00:47.28 |
| Robin_Watts | So copy mem_true64_device and blank out all the entries that you hope will never get called (like encode/decode_color etc) | 00:47.41 |
| mvrhel | ok | 00:47.55 |
| Robin_Watts | Right. So this wobbles its way through and ends up having made a fairly standard memory device. | 00:48.37 |
| | but no allocation has been done yet. | 00:48.45 |
| mvrhel | oh ok | 00:48.50 |
| Robin_Watts | Then we return to gdev_prn_create_buf_planar | 00:48.55 |
| mvrhel | yes, and the the set_planar | 00:49.10 |
| | then the.. | 00:49.14 |
| Robin_Watts | and that has a call to gdev_prn_set_planar. | 00:49.15 |
| mvrhel | and then mem_set_planar | 00:49.25 |
| | which does another gdev_mem_device_for_bits based upon bit depth | 00:49.41 |
| Robin_Watts | That overrides all the device functions with planar ones. | 00:49.51 |
| mvrhel | ok | 00:50.04 |
| | when is the buffer created? | 00:50.11 |
| Robin_Watts | Look at the next function: gdev_prn_size_buf_planar | 00:51.07 |
| | That says how big the buffer needs to be. | 00:51.34 |
| mvrhel | shoot I have to go pick up kids at piano now... | 00:52.15 |
| Robin_Watts | That's assigned to pdev->printer_procs.buf_procs.size_buf_device | 00:52.16 |
| | So we need to look where that's called. | 00:52.24 |
| mvrhel | Robin_Watts: yes. I can poke at that tonight then | 00:52.36 |
| | thanks for helping me | 00:52.45 |
| Robin_Watts | I'll keep poking and burbling for a bit. have a good weekend. | 00:52.48 |
| mvrhel | ok thanks | 00:52.56 |
| | so do I need to create a whole new version of gdevm64.c? | 00:53.05 |
| | for a generic prototype to use? | 00:53.29 |
| Robin_Watts | gdev_prn_allocate seems to call size_buf_device. | 00:53.40 |
| | Possibly, yes. | 00:53.47 |
| mvrhel | gtg. bbiab | 00:53.51 |
| Robin_Watts | cyl. | 00:53.58 |
| | mvrhel: I wonder if you wouldn't be better off walking through a complete example that uses <64 bits before trying one > 64bits. | 01:21.28 |
| | A lot of the functions in gdevm64 are to do with fill_rect etc, and you shouldn't need to implement them. | 01:22.28 |
| | so gdevmx (or gdevmbig or whatever you call it) will hopefully be smaller. | 01:23.06 |
| mvrhel | oh good idea. i will work on that | 01:58.15 |
| | Robin_Watts: for the logs. Creating a dummy memory prototype "imagex" seems to have solved the problems. thanks for point me to this. now I am making it all the way into clist playback. | 06:46.43 |
| | and I am passing my data through the clist. good way to end the night | 06:55.52 |
| sebras | Robin_Watts: are you here? | 23:36.54 |
| | most likely not, but hey, I can always try. :) | 23:37.09 |
| | in draw/draw_scale.c:add_weight() there is a comment "Ensure i is in range" below which you clamp i and return. this only clamps the function argument i, not the value passed to the function. is this really what you intended? | 23:38.53 |
| | Forward 1 day (to 2012/03/11)>>> | |
IRC Logs