Age | Commit message (Collapse) | Author |
|
A canvas is just a canvas. Move WaveView into its own library.
|
|
make libwidget independent of libcanvas.
Confine basics to pbd and gtkmm2ext.
|
|
The drawing itself should be unchanged but much of the rest of the
implementation has changed. The WaveViewThreads and WaveViewDrawingThread
classes were added and allow multiple drawing threads.
The Item::prepare_for_render interface is implemented by WaveView to enable
queuing draw requests for the drawing threads to process as soon as the state
change occurs during Editor::visual_changer, which often means the images will
be finished by the time they are needed in WaveView::render. This can
significantly reduce total render time and also flickering caused by images not
being ready for display.
If the drawing thread/s cannot finish the request by the time it is required in
WaveView::render then cancel it and draw the WaveViewImage in the GUI thread if
it is likely it can be completed in the current render pass/frame. This change
also helps reduce the flickering caused by images not being ready with threaded
rendering, but with several drawing threads, drawing in the GUI thread may not
often occur (unless explicitly requested).
Allow unfinished images to be returned from the cache in
WaveView::prepare_for_render so that new draw requests aren't queued for
duplicate images. This reduces the amount of drawing for instance in
compositions where there are many instances of the same sample/waveform
displayed on the canvas as only a single image should be drawn.
Use a random width within a certain range for
WaveView::optimal_image_width_samples so that image drawing is less likely to
occur at the same time (which will cause a spike in render/draw time and
increase the chance of flickering waveforms).
Move implementations of the private WaveView classes into wave_view_private.h
and wave_view_private.cc source files.
Incorporate a fix for limiting the waveview image size to the cairo image size
limit.
Should hopefully Resolve: #6478
|
|
This allows to re-use the concept with CairoWidget
|
|
This avoids Coregraphics (cairo_quartz_surface..) competely.
The openGL texture bypasses CG's slow argb_image and CGSColorMask
methods.
|
|
|
|
|
|
API subject to change and improvement
|
|
|
|
uselib is no longer implicit (inherited by .use). This is still incomplete,
some uselibs for non-linux variants may be missing.
bld.is_defined("HAVE_XXX") also no longer works and will have to be
changed (I think to bld.env["HAVE_XXX"]) in countless places.
|
|
|
|
other build
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
|
|
class; rename Group as "Layout" and retain only drawing semantics
|
|
|
|
|
|
|
|
The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
|
|
|
|
This reverts commit c57fcde78cc0fb393fb7420f1edbc71edf572bd0.
and also commit f1f8f89fcb9312065a818233dff4a3f1871fa7fe.
|
|
|
|
bld.env['LIBDIR']
|
|
|
|
default), -DLIBCANVAS_DLL_EXPORTS=1 is not lost
|
|
|
|
internal use; use libtimecode as a shared lib again
|
|
|
|
|
|
|
|
|
|
|
|
development, but it is just a distraction - we will NEVER be saving or restoring canvas state via XML or any kind of serialized state
|
|
threaded rendering directly into an image buffer suitable for use by cairo as a source surface (currently untested)
|
|
rectangles missing their upper line segment; more cairo canvas fixes
|
|
correctly
|