Commits on Jul 25, 2016
  1. Fix a number of memory leaks; new backend drawing features

    Large cross-patch from pd2D.  I shouldn't need to do many more of these,
    as pd2D has finally stabilized.
    committed Jul 25, 2016
Commits on Jul 13, 2016
  1. Tons of backend fixes and improvements

    Sorry for the vague commit comment; there's a lot happening in parallel
    between this and the pd2D project
    (  I'm slowly moving PD's
    rendering backend over to pd2D, which means that the same rendering
    engine will be used for the UI, paint tools, and any miscellaneous
    rendering involved in various filters and effects.
    pd2D is getting closer to a 1.0 release.  Once that happens, I can start
    dropping some long-awaited functionality into PD.  Thanks for your
    committed Jul 13, 2016
Commits on Jul 6, 2016
Commits on Jul 1, 2016
  1. Image > Straighten: large performance improvements

    pd2D makes it much easier to handle complex transformations like
    "straighten" (where multiple rotation and straighten operations are
    chained together).   I have now migrated the "Straighten" function to
    Previously, the "straighten" function had to apply rotate and scale
    functions in separate steps, for each layer, with two temporary DIB
    allocations in-between.  But no more!
    Migrating the Straighten function to pd2D yielded large speed and
    quality gains: on a 5-layer, 6 megapixel test image, processing time
    went from 21.3 seconds to 4.6 seconds - a nearly 80% reduction.  Also,
    all rotate and scale steps happen simultaneously, so only one temporary
    object is required, improving quality (by not performing two lossy
    operations) and also reducing memory requirements (because we only need
    one temp copy instead of two).  FreeImage has also been removed as a
    Gains like this is why I feel okay taking this momentary "pd2D detour" -
    there are so many benefits to using the same 2D engine throughout PD,
    instead of hand-building every operation from scratch.  By using the
    same engine to drive PD's on-canvas tools, the UI renderer, and its
    filter backends, improvements in one place are shared throughout the
    entire program.
    committed Jul 1, 2016
Commits on Jun 29, 2016
Commits on Jun 26, 2016
  1. Backport a number of pd2D feature improvements

    This includes the groundwork for the forthcoming "shape" tool, which
    will lean heavily on the vector capabilities of pd2D.
    committed Jun 26, 2016
Commits on Jun 23, 2016
  1. Continue migrating UI rendering to pd2D

    This brings significant UI performance improvements to miscellaneous
    places that were manually drawing complex features like gradients (e.g.
    PD's many colored sliders).
    Also, pd2D is now being updated in parallel against the separate pd2D
    repository (which will soon go live).  I'm not quite ready to pull in
    pd2D as its own submodule, as there are still quite a few PD-specific
    edits in modules like the GDI+ wrapper, but the goal is to eventually be
    able to rely on pd2D as a completely standalone library, with no
    PD-specific bits.
    committed Jun 23, 2016
Commits on Jun 22, 2016
  1. pd2DPath: finish (I think?) migration to new engine

    pd2DPath has finally been purged of any GDI+ specific code, and it
    should now be leak-proof (I hope; further testing still ongoing).
    I'm pretty darn close to splitting out the pd2D bits into their own
    repository, so that's exciting.
    committed Jun 22, 2016
Commits on Jun 21, 2016
  1. pd2DPath: migration to pd2D engine about halfway complete

    The class now successfully self-manages its own handle, all the
    requisite pd2D functions have been added, and all internal GDI+
    management functions have been split out into the GDI+ module.
    Still to-do is migrating the various line/shape functions to a
    backend-agnostic solution.
    committed Jun 21, 2016
  2. pd2DTransform: the latest addition to the pd2D family

    The class formerly known as pdGraphicsMatrix has been cleaned up and
    greatly expanded, and it now behaves like the rest of the pd2D library.
    Paths in particular use a lot of transform operations, so this was a
    necessary step on the way toward completing the (incredibly tedious)
    pd2DPath class.
    committed Jun 20, 2016
  3. pd2DPath: finish purge of all drawing code

    This was a big project, and it's great to have it done!  Instead of
    self-painting, all path objects can now be painted via pd2DPainter, as
    you'd expect.
    Next up: converting the rest of the class to the pd2D system.
    committed Jun 20, 2016
Commits on Jun 20, 2016
  1. Large clean-up of various GDI interop functions

    I'm slowly moving GDI interop bits into a dedicated GDI-only module,
    which will both 1) make it easier to convert pd2D to a standalone
    library, and 2) help clean-up PD's rather messy code layout.
    As part of this commit, pd2DSurface objects can now be created from
    scratch (e.g. without the requirement to wrap an existing DC).
    Internally, the surface is managed using pdDIB, which makes things like
    GDI interop much simpler.
    Also, pdSurface objects can be queries for the width, height, stride,
    and alpha support.  Surfaces wrapped around external DCs will
    automatically query the DC for this information, as necessary.
    committed Jun 20, 2016
  2. pd2D: implement texture brushes

    This greatly simplifies tasks like painting a checkerboard background,
    which PD does with extreme frequency.  By caching that brush globally,
    we don't need to re-create it for every individual control/window that
    needs to paint a transparency background.
    (Previously, the checkerboard *image* was cached globally, and a brush
    was dynamically wrapped around it on-demand.  There's probably little
    performance difference between the two approaches, but this makes me
    feel better while also requiring less code.)
    Still to-do is thinking up a good way to implement textures for PD
    tools.  The problem is not texture brushes/fills themselves (that part's
    already done).  The problem is how best to store/retrieve texture brush
    settings from file, if a vector layer (e.g. a shape) is filled with a
    raster texture.  We could serialize the entire texture to a Base-64
    string, but that might be ridiculously huge depending on the texture.
    My preferred choice is probably to dynamically assign some kind of
    "texture resource ID" inside the file, then store the texture itself as
    some kind of specialized resource inside its own pdPackage node.  The
    format is well-equipped for such an approach.
    But this still isn't a full solution.  What happens if some other user
    loads a downloaded PDI file with vector layers that use embedded raster
    fills?  Do we automatically add those textures to the user's PD texture
    collection, or do we stick them somewhere special, in a "per-image"
    resource group?  What kind of management is required to move resources
    between the per-image group and the core PD resource group?
    I don't have answers to any of this yet, which is why I haven't
    implemented texture brushes program-wide.  At this rate, they probably
    won't make the cut for 7.0, but at least they are internally accessible
    so I can do lots of preparatory testing on them.
    committed Jun 20, 2016
  3. pdPenSelector UI: migrate to pd2D

    This was a pesky one as the control makes use of multiple clipping
    regions and some other weird features, but these things are now just a
    few lines of code thanks to recent pd2D work.
    committed Jun 20, 2016
Commits on Jun 19, 2016
Commits on Jun 18, 2016
Commits on Jun 17, 2016
  1. Viewport engine: migrate to pd2D, implement UI pen and brush caching

    Pen and brush creation is trivial from a performance standpoint, but it
    doesn't hurt to cache a few of the most-used items.  pd2D makes this
    much simpler than it would otherwise be, and a few other viewport
    elements have been cleaned up, including cleaner rendering of layer
    transform nodes and borders.
    committed Jun 17, 2016
  2. pdGraphicsPath: start refactor to merge into pd2D

    This is gonna be a slog, but when it's done, I'll finally have a
    high-powered 2D drawing library with no PD-specific dependencies.
    (Also, it's a great chance to revisit a number of old drawing functions
    throughout PD, and many minor bugs are being fixed as I go - so there's
    absolutely worth to PD as well.)
    committed Jun 17, 2016
  3. pdTitle: migrate to pd2D

    This was the only control that used the old "draw gradient line"
    functions, and said functionality can now be handled by a pd2DPen
    created from a pd2DBrush gradient.
    committed Jun 16, 2016
  4. pdGradient: make opacity use [0, 100] range like everything else

    It was using [0, 1] internally, which was confusing and ill-conceived.
    Apologies if this messes up any files saved with the current nightly
    builds - you'll need to manually adjust all gradient point opacities
    from "1" to "100" to compensate.
    committed Jun 16, 2016
  5. pdPen: you can now create pens from brush objects

    This is the only way to create certain types of pens, e.g. gradient or
    texture pens.
    committed Jun 16, 2016
Commits on Jun 16, 2016
  1. Gradient brushes: new features and improved design

    Gradient brushes are looking a lot better these days, and after this
    large refactoring session, new features will be much easier to
    committed Jun 16, 2016
  2. Brush/fill dialog: overhaul UI

    New features makes it possible to simultaneously provide a much larger
    preview, and much more room for individual settings.
    committed Jun 16, 2016
  3. pdGradient: allow node settings to be handled as a standalone string

    This makes them get/settable like any other gradient property, which
    makes it much easier to do something like create two brushes - one
    linear, one radial - with matching point distribution.
    committed Jun 16, 2016
Commits on Jun 15, 2016
  1. Gradient editor: continued refactoring

    Lots of changes here, but the details aren't really important.  In a
    nutshell, the ongoing goals of these refactors includes...
    1) making drawing classes PD-agnostic, so pd2d is viable for external
    users.  (pdGradient is required by the brush class, so a crucial
    2) getting PD's gradient-related UI reworked so that the gradient editor
    is *only* for editing gradient colors.  Shape, angle, and other features
    need to be external.  (This is important for future tools, like Gradient
    Map, that only require gradient color data; they don't actually draw
    gradients on anything.)
    This commit solves (2) and gets closer to solving (1).
    Also, due to some unpleasant underlying VB bugs
    (, pdContainer instances
    may need extra revisiting on certain dialogs, as they did here.  I'll
    probably end up writing my own picture box replacement so I don't have
    to deal with this annoyance throughout all of PD, but that's still
    committed Jun 15, 2016
  2. pdWindowPainter: allow parent window to request WM_ERASEBKGND messages

    Most of PD's controls are double-buffered, but for some, it doesn't make
    sense (e.g. the new pdContainer control).  As such, these controls need
    to heed WM_ERASEBKGND messages.
    A simplified interface between pdWindowPainter and pdUCSupport makes
    this automatic.
    committed Jun 15, 2016
  3. Migrate many dialogs to pdContainer

    Another ~20 dialogs are now fully themed, thanks to this.
    Because these edits were made in an external editor, there may be minor
    issues I've missed (but nothing that affects compilation, thankfully).
    Many dialogs still need to be revisited for other UI reasons, but this
    is a good start toward solving remaining theme-related issues.
    committed Jun 15, 2016
Commits on Jun 13, 2016
  1. pdContainer: a new solution to control containers

    Historically, PD has used bare "picture box" controls to handle groups
    of related controls.  This solution has a lot of problems:
    - Picture boxes use a lot of resources
    - Picture boxes aren't themable
    - Picture boxes suffer from the same high-DPI issues as other VB
    To solve these issues in one fell swoop, I've now created a pdContainer
    user control.  This lightweight control has just one purpose: to house a
    bunch of other controls in a convenient high-DPI- and theme-friendly
    All toolboxes and panels on the main window have been rolled over to
    this new system, meaning just about everything in the main window is now
    themed correctly.  (FYI the layer box is still to-do, as are elements of
    the primary canvas, but everything else is ready.)  A few more hWnds and
    GDI objects are also shaved off a cold start thanks to this.
    Still to-do is... well, every standalone dialog in the project, which is
    going to be immensely ugly.  But as menial as the rollover will be, this
    is definitely the right solution vs trying to retrofit theming and
    high-DPI support onto existing picture box instances.
    committed Jun 13, 2016
Commits on Jun 12, 2016
  1. pdDIB: clean-up and optimization

    This class inevitably grows between releases, and it's always good to
    get its size back down.  A number of esoteric functions have been
    migrated to the DIB_Support module, some class-level variables have been
    dropped, and as I've been meaning to do for some time, a convenience
    function for wrapping an array around a DIB has now been added.  (With
    this function the caller must also provide their own SafeArray, by
    design; this works well enough for matching the array's scope, and it
    also gives the caller a way to query the array's properties, as needed.)
    committed Jun 12, 2016
  2. Effects > Blur > Zoom blur: minor code clean-up

    Also, 32-bpp data is now correctly blurred in the premultiplied alpha
    committed Jun 12, 2016
  3. Effects > Blur > Zoom Blur: new algorithm

    While the old implementation of this tool was quite fast, it required
    that the effect's center point be the actual center point of the image.
    That greatly reduced the tool's usefulness!
    So a new implementation was required.  The new implementation is slower
    (alas), but there's far less distortion at low effect levels, and any
    center point can be used.  A number of heuristics are in place to try
    and keep performance "okay", but additional suggestions are of course
    (Pending additional testing, I may roll out a similar update to the
    radial blur tool, as its current implementation suffers from the same
    committed Jun 11, 2016
Commits on Jun 11, 2016
  1. Adjustments > Color > Replace Color: add LittleCMS L*a*b* pathway

    As with yesterday's commit for the "green screen" tool, this improves
    performance by some ~30%.
    committed Jun 11, 2016