| Age | Commit message (Collapse) | Author |
|---|
|
The put_pixel helpers really needed reworking to properly handle
subframe fragments modules like montage will utilize. I had the
stride present as it's convenient for a number of modules that
maintain a buf pointer as they progress down a row, but the pitch
is more applicable to put_pixel for scaling the y coordinate.
Now there's both pitch and stride so everyone's happy with what's
most convenient for their needs.
|
|
For the sake of sdl_fb, move page flipping into the main thread
and run module render dispatch from another thread instead.
This eliminates the fb flipper thread, moving its functionality
into fb_flip() which synchronously consumes and performs a single
flip from the same queue as before - the function is verbatim
the loop body of the flipper thread.
Now main() calls fb_flip() in a loop where it previously dispatched
pages for rendering.
Rendering dispatch is now performed in a created thread.
See the comment in fb.c for more explanation of this shuffle.
|
|
The fb_ops entrypoints and their descendants are purely readers
of the settings, so constify their settings_t instances and the
operative functions which only read settings.
|
|
This should probably be split into multiple commits, but
for simplicity sake it's all cut over at once.
drm_fb.c sees major changes, migrating the remaining drm-specific bits
from drmsetup into it, behind the settings API.
rototiller.c sees a bunch of scaffolding surrounding the settings API
and wiring it up into the commandline handling and renderers and video
backends.
fb.[ch] see minor changes as settings get plumbed to the backend
drmsetup.[ch] goes bye bye
|
|
Remove everything drm-related from fb.c, utilizing the implementation in
drm_fb.c instead.
|
|
Hooks for fb acquire/release, page allocate, free, and flip.
This should encompass everything currently needed for the drm backend,
which will move behind this abstraction in a later commit.
|
|
Mechanical cosmetic change
|
|
|
|
Rather than laying out all fragments in a frame up-front in
ray_module_t.prepare_frame(), return a fragment generator
(rototiller_fragmenter_t) which produces the numbered fragment
as needed.
This removes complexity from the serially-executed
prepare_frame() and allows the individual fragments to be
computed in parallel by the different threads. It also
eliminates the need for a fragments array in the
rototiller_frame_t, indeed rototiller_frame_t is eliminated
altogether.
|
|
fb_fragment_put_pixel_unchecked() assumed the x,y coordinates of
the fragment were always 0.
|
|
Modules need to know the overall dimensions of the frame the fragment
they're rendering is part of. Previously it wasn't really necessary
since the fragments supplied to the modules had always been the full
page, but that's changing.
This commit also changes the julia module to use the frame dimensions,
others will need updating as well.
|
|
Currently just a memset wrapper... but maybe could get noop'd if
the flipper thread started supporting pre-zeroing pages in its thread,
just need a zeroed state in the fb page.
|
|
Modules seem to be duplicating this, just pull it into fb.h since we're
already dependent on the fb.h abstractions in the modules. Slippery slope!
|
|
Simple x,y coordinate check
|
|
Restoring some organizational sanity since adopting autotools.
|
