freenode/#shirakumo - IRC Chatlog
Search
12:34:24
|3b|
i think i just assumed single atlas, since most hardware supports pretty big textures these days
12:47:22
Shinmera
So if I pass :flip-y NIL to pngload the UVs do display something, but the letters are upside down.
12:51:12
|3b|
worked in virality, but possibly just by luck (or due to some odd configuration there)... wouldn't be surprised if it is wrong in general though
12:54:19
Colleen
github.com/Shirakumo/trial/... Website (HTML), Title: trial/workbench.lisp at master · Shirakumo/trial · GitHub
12:55:16
Shinmera
Easier to add than expected. Can't replace the current system quite yet though, since I can't generate the atlas in-engine yet.
12:58:53
|3b|
msdf seems to be a reasonable 'good enough' level, which is why i'm not super motivated to work on the direct vector rendering, but does have issues with more complicated characters
13:09:57
|3b|
hmm, seems to be lots of duplicates, will have to check on that next time i mess with my sdf generator
13:16:01
|3b|
also, i think https://github.com/Shirakumo/trial/blob/master/workbench.lisp#L15-L20 might not be right... you should probably just set texture format from # of channels in atlas
13:16:01
Colleen
github.com/Shirakumo/trial/... Website (HTML), Title: trial/workbench.lisp at master · Shirakumo/trial · GitHub
13:18:17
|3b|
i think those alpha-chnl etc fields say what is in the channel, not whether it exists (and might not even be meaningful in msdf variants of the format... not sure all the generators agree on that)
13:19:35
Colleen
www.angelcode.com/products/... Website (HTML), Title: Bitmap Font Generator - Documentation
17:02:44
Shinmera
|3b|: I started writing a more general version of MAP-GLYPHS that could be used in conjunction with bidi, but I'm realising it's basically all just an LTR layouting algorithm, which should probably be done entirely in a different library, together with other layout options.
17:03:48
Colleen
github.com/3b/3b-bmfont/pul... Website (HTML), Title: Fix vertical normalisation when mapping glyphs. by Shinmera · Pull Request #9 · 3b/3b-bmfont · GitHub
17:07:38
Shinmera
I guess I'll PR the other thing as well, up to you whether you want to merge it though.
18:22:01
mfiano
It also works with nil to flip them. I just re-integrated pngload into our engine with images of differing origins
18:23:00
mfiano
Yeah was just responding to Shinmera │ Oh, right, I think the :flip-y option in pngload stopped working some time ago?
18:23:26
Shinmera
That was a thing I remembered wrong from when I was last ripping my hair out about origins.
18:25:16
mfiano
SO you have to decide whether to store images on disk wrong, rewrite UV buffer after parsing binary data, fix every shader, flip pixels with image loading lib, etc
18:27:38
mfiano
Much worse if you use a format like TGA, which allows the artist to save the origin in any of the 4 corners!
18:56:40
mfiano
Shinmera: btw I just pushed to pngload some changes 3b made which swaps out chipz for his thing. Should be closer to 2x faster now
20:42:56
mfiano
Currently the decoding process is about 75% of the time. Only 25% for decompresion now.
20:44:51
mfiano
I'd actually like to discuss it with someone smarter with me if you ever get time :)
20:49:09
Shinmera
I'm typically not an optimisation guru, so I'm not sure how much help I'd be in that.
20:50:18
mfiano
The way decoding works, is it looks at each row of pixels in order. For each pixel, depending on the filter method for that row, looks at either the left pixel, the top pixel, or both, in order to change the current pixel (this is called unfiltering in the spec). So we have to iterate each row in order which is slow. I'd like to parallelize this process with a thread pool. But that involves batching
20:50:21
mfiano
scanlines in groups of two (so it has the previous row available for when it has to look at the top pixel).
20:53:22
Shinmera
You could divide the image into quadratic batches and kick off threads in a diagonal fashion as dependencies become fulfilled.
20:54:38
Shinmera
Well, as you describe it each pixel has a dependency on the one above and the one to the left, meaning as the dependencies unravel the "frontier" moves diagonally across the image.
20:55:10
Shinmera
Since using a task for each pixel is too expensive and fine grained, you'd instead divide the image into batches to compute, and have the same dependency scheme across the batches instead.
21:03:01
Shinmera
That's pretty good. I presume you already looked at sprof output and everything, yeah?
21:03:50
mfiano
It shows about 75% of the time spent doing this unfiltering, and that's with heavy compiler optimizations me and 3b added over the years
21:07:31
mfiano
Depends on how fine grained you sub divide. Small 32x32 images parsing in parallel have significant gains, so I don't think this is too worrisome
22:29:03
mfiano
I should be able to look at the filter method of all rows first, and then process the ones with the None or Sub filters first in parallel (the ones where pixels are unmodified or depend on the left pixel). Then the sparse rows can be processed diagonally
23:34:13
|3b|
Shinmera: yeah, map-glyphs was as a minimal "get something working" api, and real layout should probably be a separate lib. no idea what APIs would be useful for that beyond just the raw data without writing it though :)
23:34:55
|3b|
mfiano: threading pngload doesn't seem too useful to me, i'd probably just do SSE stuff and thread at whole-image level