Skip to content
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
    implement.
    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
    component)
    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
    (https://support.microsoft.com/en-us/kb/188552), 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
    to-do.
    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
    controls
    
    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
    way.
    
    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
    space.
    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
    welcome.
    
    (Pending additional testing, I may roll out a similar update to the
    radial blur tool, as its current implementation suffers from the same
    problem.)
    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
Commits on Jun 10, 2016
  1. LittleCMS: new support for fast sRGB <-> L*a*b* transforms

    The new code was tested on PD's "green screen" function (Layer >
    Transparency > Make color transparent...).  Performance boost is roughly
    30%, so a nice boost.  (Specifically, on a 20mp test photo with settings
    that involve 80+% of the image being removed, running time dropped from
    ~30 seconds to ~20 seconds using the LittleCMS code path.)
    
    The old, non-LCMS path is still available, and will automatically be
    triggered if LittleCMS goes missing.
    committed Jun 10, 2016
  2. Add theme settings to Developer menu

    It's time to start testing theme options throughout the program.  Still
    TBD is a good solution for control containers; these currently look
    terrible under the dark theme, but I couldn't easily rectify the problem
    without these new testing menus.
    
    Also, I haven't made a final decision on how to present theme options to
    the user.  Checked menus like this are kind of meh, but I'm not sure I
    want to build a dedicated "theme browser" dialog just yet.
    
    I'll have a better idea of how much I want to expand theme options after
    testing them program-wide.  (For all I know, there are horrible
    scenarios I haven't considered yet, and this whole thing is a terrible
    idea!)
    committed Jun 10, 2016
  3. Basic SVG import framework

    When I say "basic", I mean *basic*.  Right now, all the import function
    does is create an image at the same dimensions as the default ones
    specified by the SVG.
    
    I'm interested in SVG parsing for a lot of reasons, but primarily
    because it's a great format for PD's forthcoming shape tool.  Being able
    to define shapes as SVG would save me a lot of grief, and it would make
    it easy for users to create and/or import shapes from other sources.
    
    Also, XAML uses a very SVG-like format, and Paint.NET defines all its
    shapes using XAML.  An intelligent parser could accept either format,
    and convert the result to a pd2DPath suitable for rendering within PD.
    
    Anyway, I'm not sure how far I'm going to take this, but seeing as there
    are zero VB-compatible SVG libraries (Cairo is probably the closest,
    ugh), this could be an interesting project to whittle away at.
    
    As for technical details: what I'm doing at present is coercing ExifTool
    into parsing the SVG for me, and returning a well-defined list of SVG
    entries and attributes.  For basic SVGs this works well enough, and it's
    a nice shortcut until we devise a more sophisticated parsing approach
    (e.g. manually walking the actual XML DOM, which would be necessary for
    more complex files).
    committed Jun 10, 2016
  4. Metadata parser: harden against parsing errors

    Turns out lots of bad software will write multiline tags in places where
    line breaks are forbidden.  Argh.
    committed Jun 10, 2016
Commits on Jun 9, 2016
  1. Brightness/contrast: total overhaul

    Standard brightness/contrast adjustments are total garbage from an image
    quality standpoint.  They cause highly destructive clipping at both ends
    of the luminance spectrum, which makes them all but useless to
    professionals.
    
    Unfortunately, casual users still default to the brightness/contrast
    tool simply because they don't know better.  Adobe developed a clever
    solution to this in Photoshop CS3: they silently rolled the
    brightness/contrast tool over to a much more sophisticated algorithm,
    then added a toggle for "legacy mode" to restore the old behavior, if
    desired.
    
    I like this a lot, so I've now done the same thing in PD.  Courtesy of
    LittleCMS, the new brightness/contrast tool defaults to an extremely
    high-quality L*a*b*-based adjustment.  This allows for very subtle
    brightness/contrast tweaks, and if for some reason the old algorithm is
    needed, there's a toggle to restore it.
    
    As an FYI, the new algorithm is only ~1x slower than the legacy
    LUT-method, which gives an idea of the SIMD benefits LittleCMS provides
    (considering we're doing a round-trip RGB <-> L*a*b* conversion!).
    committed Jun 9, 2016
Something went wrong with that request. Please try again.