Since 74fe396cc5 compute_bounding_box() by itself does not do the entire computation, so we
must call into Item::bounding_box() to get the result with children added also
ConstraintPacker is the one Item-derivative that should NOT call Item::size_allocate_children()
because it just did the size computation for its children and called their
::constrained() method, which in turns calls size_allocate() with the correct size
This previously wasn't done because of fear that it would affect the traditional fixed-sized canvas,
but only items that _layout_sensitive (i.e. are packed into a constraint packer directly) will
actually do anything in ::size_allocate().
Possibly might want to relax this to cover items that have a constraint packer between them
and a root group.
This means that a request to (re)draw the Rect (0.5,0.5,9.5,9.5)
will actually generate an expose event for (0,0,10,10)
Note: the above rects are of the form (x0,y0,x1,y1)
Items call ::queue_resize(), which sets a flag in the canvas; at next idle, we call
Canvas::layout() which walks the item tree and recursively calls layout (depth first)
on all items needing a resize.
Only Container types implement layout, and so far only Box
Polygons used PolyLine::render() to render the path.
However since 7bb8ca1e76, the PolyLine path is constrained
(for automation lanes), and closed shaped polygons were not
always completely redrawn.
Cairo::curve_to renders cubic Bézier splines, those are not
generally useful in a DAW context.
Canvas::Curve implements centripetal catmull-rom spline drawing
which can be used for fades and automation interpolation.
Previously this was inherited via PBD.
On MacOS/X, this adds
"-undefined dynamic_lookup -flat_namespace"
and various "-framework .." options to linkflags
Without this flag, .dylibs fail to link usually because
of missing `-lintl` (Undefined symbols: "_libintl_dgettext")
On other systems this is a NO-OP:
CFLAGS_OSX, CXXFLAGS_OSX and LINKFLAGS_OSX
are only set on the darwin platform.
This partially reverts 2edbda2526.
Using cairo-groups increases performance on MacOS, and retains
retina-resolution.
However it adds a performance regression for MS Windows graphics
rendering. cairo-groups use a "similar" surface, not an image surface.
Empirically this adds significant overhead compared to rendering
using the CPU and using bitblt.
For MacOS/X this is equivalent, rendering happens using a
CGBitmapContext + image-surface. Windows and Linux needs profiling
for respective equivalent surfaces.
This is an intermediate commit, before replacing image surfaces with
cairo pattern groups.
The eventual goal is to reduce flickering and/or use
CPU + bitblt for specific widgets instead of cairo
graphics-cards accel.
This also removes excessive calls to getenv() for every rendering
operation.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
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
Called when an item has requested a redraw and intersects with visible
canvas area.
Also add Canvas::prepare_for_render that will call Item::prepare_for_render for
items visible on the canvas.
With large sample-rates and high-zoom-level the minimal request-size
or at least 1/10sed can exceed the max image size supported by cairo.
e.g. @192kSPS; 100ms = 19200 samples.
* 1 sample/pixel, * 2 (left/right) = 38400px > 2^15px.
