This partly reverts commit ad28684b10.
Prior to that change, getBrush() would always end up calling
SetTransform on gradient/image brushes. This is important because, when
drawing text, we combine the current brush transform with the text
transform. If we don't reset the brush transform each time, these
transforms end up accumulating across frames.
The code contains a performance optimisation for cases where the world
transform is translation only. In this case instead of applying the
brush transformation first and then the world translation, the order is
reversed. The translation is applied first and then the brush
transformation.
Flipping the transformations however is only correct in the special case
when both transformations are translation only.
Reverts ca3abbb96d.
Prior to this fix gradually changing the Component scale would lead to
the jittery movement of drawn bitmaps, as their position would be
snapped to an arbitrary integral representation.
This addresses the same issue that
95d416ab77 was intended to fix:
Drawing a drop shadow on a high-res display on Windows could sometimes
produce thin lines around the edge of the shadow. Using the 'clamp'
rather than the 'wrap' clipping mode seems to help.
Previously, plugins and standalone apps could produce slightly different
visual results, particularly anti-aliasing, when displaying on a display
with native scaling applied. The discrepancy was caused by SetDpi being
called with a larger-than-default value (e.g. 192 DPI on a 200% scaled
display) in a standalone app, whereas SetDpi would always be called with
the default value of 96 in a plugin.
Keeping the default value seems to produce better results, so standalone
apps will now retain the default DPI.
This issue could be observed in the GraphicsDemo's SVG pane, when the
"rotation" option was enabled.
Drawables internally enable the unclipped painting flag, which normally
prevents slow clipping when drawing subcomponents of the drawable.
The Direct2D graphics context was using the frame area as the default
area, used to signal that no clipping should be applied. However, when
non-axis-aligned transform was active, this area was incorrectly applied
as a geometric clipping region. D2D geometric clips are relatively slow,
so this caused large slowdowns.
This solution adds a flag that is set whenever a clip is explicitly
requested. If no clip is explicitly requested, then clipping will be
entirely bypassed. This can make rendering of Drawables significantly
faster.
Previously, IDXGISwapChain::Present was called on a background thread,
which made it difficult to avoid race conditions. e.g. during a
live-resize of a window, we would occasionally draw old incomplete
frames instead of new frames at the correct size.
The new approach moves the Present call to the main thread via
AsyncUpdater. We attempt to present whenever the swap event wakes, and
whenever a frame is drawn. Only a single Present call may be made after
the swap event wakes. Subsequent Present calls will be ignored until the
next time the swap event wakes.
This assertion was intended to emulate a performance warning that could
be emitted by the D2D debug layer, but it often gets in the way during
development. To check for this performance issue, users can change
D2D1_DEBUG_LEVEL_NONE to D2D1_DEBUG_LEVEL_INFORMATION in
juce_DirectX_windows.h
This issue could be seen when calling setBufferedToImage on a component
with a transparent background with a size different to the component's
size.
The details are unclear to me, but it seems like both calling Clear on
the device context, and using the COPY blend mode, ignore alpha values
and instead use a constant alpha of 1.0 when there is a geometric
clipping layer active.
As a workaround for this issue, when clearing a rectangle we now pop all
active layers, fill their intersection using the COPY blend mode while
there are no layers active, and then reinstate the layers.
The new implementation is likely to be very slow, however I think this
code path is unlikely to be used frequently in practice. The main
use-case for rendering clear transparent areas is the rendering of
buffered component images, but such cases normally use axis-aligned
clipping regions, which should be able to use the faster path.
Frequently, excludeClipRectangle will be called several times in a row,
in order to trim away borders on each side of a rectangle. When this
happens, we want to avoid creating geometric clip layers which exclude
only two or three of the borders, and instead wait until all borders
have been excluded before applying the clip list. This way, it may be
possible to simplify the clip list to a single rectangle, which can be
implemented using the faster axis-aligned clipping layer.
This assertion is intended to mirror the behaviour of an
informational/performance diagnostic message raised by the D2D debugging
layer.
It seems the D2D diagnostic is raised when the proposed clip region is
aligned to the screen, not to the current transform.
Before this change, the assertion could incorrectly fire when clipping
to transformed rectangles. This could be seen when clicking the
star-shaped buttons in the ComponentTransformsDemo.
With this change in place, the assertion will still fire when e.g.
calling Graphics::reduceClipRegion on a screen-aligned rectangular path,
but will not fire when this path is skewed/rotated etc.
