| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
one less mystery
|
| |
|
|
|
|
|
| |
It necessarily removes the config.images check from codec access, which
I'm not quite happy about, so I've added a check to the DOM instead.
(TODO: maybe pager should just dynamically grant codec access as a
capability instead? but maybe that's even more error prone...)
|
| |
|
|
|
| |
* line, vector, matrix -> path
* twtuni, charcategory -> twtstr
|
| |
|
|
|
|
|
|
|
|
| |
* consistently use cint instead of FileHandle
- this was another remnant of winapi support; on posix, they are
the same.
* move "blocking" field to PosixStream
* recvFileHandle -> recvFd, sendFileHandle -> sendFd
* merge serversocket into dynstream
* merge auxiliary C functions into dynstream_aux
|
| | |
|
| |
|
|
|
|
| |
* fix broken int conversion in dynstream
* fix EPIPE handling in forkserver
* merge fdmap and connectingContainers into loader map
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* refactor parseHeader
* optimize response blob()
* add direct "to cache" mode for loader requests which sets stdout to a
file, and use it for image processing
* move image resizing into a separate process
* mmap cache files in between processing steps when possible
At last, resize is no longer a part of image decoding. Also, it feels
much nicer to keep encoded image data in the same cache as everything
else.
The mmap operations *should* be more efficient than copying the whole
RGBA data through a pipe. In practice, it only makes a difference for
loading (well, now just mmapping) the encoded image into the pager,
where it singlehandedly speeds up image display by 10x on my test image.
For the other steps, the unfortunate fact that "tocache" must delay the
next fork/exec in the pipeline until the entire image is processed seems
to equal out any wins we might have gotten from skipping a single raw
RGBA copy.
I have tried moving the delay before the exec (it's possible with yet
another pipe), but it didn't help much and made the code much
uglier. (Not that tocache didn't, but I can live with this...)
|
|
|
Module boundaries didn't make much sense here either. Specifically:
* loader/cgi was originally just one of the many "real" protocols
supported by loader, so it was in a separate module (like the other
ones). Now it's mostly an "internal" protocol, and it was getting
cumbersome to pass all required loader state to loadCGI.
* The loader interface has grown quite large, but there is no need for
(or advantage in) putting it in the same module as the implementation.
Now CGI is handled by loader, and the interface is in the new module
"loaderiface".
|