Program Testers

[Tanner_H]

I would appreciated your contribute, that for sure would be very usefull ( times ago I look at your Photodeamon - really great) but I am not going to open-sourcing... .. at least for now.

Okay, no problem. I will try to guess at implementation details, to hopefully provide useful advice.

First off, this is a really impressive project. It reminds me a lot of DAWs, with the concept of a "chart" layout, and connecting nodes between operations. I think it is a really promising approach, with many neat possibilities.

Unfortunately, I think there are two serious problems with the program's current state.

1) Interface

I noticed a lot of strange issues with the interface. For example, when working with wallpaper-sized images, the image preview would constantly "jump" to the foreground. Sometimes, clicking on the tool option box (which appears after clicking an effect node) doesn't work. I think the form in the top-right is stealing focus or something. The options window doesn't appear to be movable, so this makes it really hard to use.

Then there are little oddities like every item in the Input drop-down box being highlighted (???).

I also can't figure out a way to delete unneeded nodes. I tried right-clicking, backspace/delete, and a whole bunch of other interactions. No luck.

The help PDF did explain how to remove connecting lines, thankfully. It would be very nice to be able to click anywhere on a line to access it, instead of just the ends (as the ends are close together and difficult to target).

Anyway, these kinds of little things can take a lot of energy to address, but in my experience, these little "papercut" issues can drive users crazy.

2) Performance

To be honest, performance is pretty poor right now, especially if working on anything larger than about 0.5 megapixels. The program is more or less unusable on photographs, unless maybe you leave it to run overnight.

But don't lose hope! VB may be old, but we can coax a lot of performance out of it. You just have to be willing to read a lot of research papers and brush up on all your math skills.

Here are some quick comparison timings, using a 1920x1200 JPEG, and a single effect, applied to each RGB channel (so just three nodes: Input > Effect > Output). I also tried to stop the timer before saving the image file, so only the effect is counted:

Bilateral smoothing, radius 9, single iteration
- Photo Modular (pure VB, I assume): 197.0 seconds
- PhotoDemon (pure VB, using Effects > Noise > Remove Noise which is really bilateral smoothing): 2.0 seconds
- GIMP (C, Blur > Selective Blur which is the closest thing they offer to bilateral smoothing): 3.0 seconds

I include PhotoDemon not because it's particularly good (PhotoShop is much faster, unfortunately), but to let you know that VB is still okay for tasks like this. Bilateral smoothing seems like a particularly important tool to optimize in PMFX, because it is iterated multiple times (multipass) for some effects.

Next, let's look at something simple like Gaussian Blur. Since it's an easier function, let's test a slightly larger radius (25 px):

- Photo Modular (pure VB, I assume): 128.0 seconds
- PhotoDemon (pure VB): 1.1 seconds (iterative box blur), 1.6 seconds (IIR), 3.2 seconds (true Gaussian)
- GIMP (C): 0.5 seconds (IIR or RLE, both are very fast)
- Paint.NET (C#): 1.5 seconds

I often use GIMP and Paint.NET as my benchmark, since they represent standard performance for free photo editors. For PMFX to be in the neighborhood of those programs, it needs to be about 100x faster. I don't think this is too hard (and maybe Cairo/vbRichClient can speed up functions even more), but it's difficult to give specific advice without knowing how you've implemented your features.

Anyway, I know it is frustrating to hear things like "performance must be better," but don't lose hope. Even small fixes can sometimes make huge improvements. I also think better performance would make it easier for people to appreciate all the things your software can do.

If you'd like help or resources on any particular operation, let me know, and I'd be happy to go into more detail.

[reexre]

I noticed a lot of strange issues with the interface. For example, when working with wallpaper-sized images, the image preview would constantly "jump" to the foreground. Sometimes, clicking on the tool option box (which appears after clicking an effect node) doesn't work. I think the form in the top-right is stealing focus or something.

Fixed
The cause was RichTip trying to Draw itself outside the screen.

I'll update the "download" soon (above 0.0.815)

[ColinE66]

Fixed
The cause was RichTip trying to Draw itself outside the screen.

Hi reexre, if you have found a bug with RichTip, can you please post details of how to reproduce in the RichTip thread. Thanks...

[reexre]

Hi reexre, if you have found a bug with RichTip, can you please post details of how to reproduce in the RichTip thread. Thanks...

Create a RichTip for a picturebox on MouseMove. Make its to the Right of the picture.

Now, if the picture is bigger (width) than screen... there was the error

[ColinE66]

Create a RichTip for a picturebox on MouseMove. Make its to the Right of the picture.

Now, if the picture is bigger (width) than screen... there was the error

Thanks - I'll look into it....

[reexre]

I'm developing vbRichClient Interface

[DOWNLOAD] interface V0.1 source code

The point is that I had to draw Splines in the same canvas where CairoControls are drawn ( a picturebox )

The problem is that there's a strange flickering... I want to eliminate.

Some Code:

The Picture must be resizeable, so at Form_Resize:
(where Public vbDR As cVBDraw already initialized)

    vbDR.ReleaseBinding

    frmMain.PIC.Width = newW
    frmMain.PIC.Height = newH

    Set vbDR = Nothing
    Set vbDR = Cairo.CreateVBDrawingObject
    Set vbDR.Srf = Cairo.CreateSurface(frmMain.PIC.Width, frmMain.PIC.Height, ImageSurface)       'size of our 

rendering-area in Pixels
    Set vbDR.CC = vbDR.Srf.CreateContext    'create a Drawing-Context from the PixelSurface above

    vbDR.BindTo frmMain.PIC

After Drawing Lines with vbDR.cc....MoveTo, LineTo, Stroke
Look at Sub DrawLinks

   
   vbDR.Srf.DrawToDC frmMain.PIC.hDC
   frmMain.PIC.Refresh

Hope for a big help by Olaf

[Schmidt]

Hope for a big help by Olaf

Well, have taken a look - and considering your GUI-structure (not that many controls,
just complex drawing) - I'd *strongly* suggest to do an "all out Widget-based version"
(instead of the "workaround" with the VB-Usercontrols).

See, the cVBDraw-Class is mainly thought, to draw directly onto the BackBuffer-Surface
on a cWidgetForm with (then antialiased working) "classic VB-Drawing-Commands" (as Line and Circle).

The PictureBox-Binding-Mode you currently use it with, was not thought to act as a
"Control-Container for Windowless-UserControls on top" - I've implemented it mainly for
PDF-PrintPreviews ... (still suprised, that it works at all, though only to a degree - as you discovered).

Please take a good look at the Demo I posted here:
http://www.vbforums.com/showthread.p...r-Connections)



This is far less code than what you currently have, flickerfree and in a good performance,
Hovered-Highlighting supported above ConnectionPoints, as well as over the Bezier-Curves.

And your current Panel (based on a PicBox currently) you could easily implement with
a "sliding-in-panel" which is fully Alpha-aware, when you'd use a cWidgetForm instead
of your current Picture-Box.

The Widget-Engine might have a bit of a learning-curve - but when you consider the time you
invested over the last days (for the VB-UserControl-based solution) - if you invest half
of that into learning how to use the Widget-Engine, you'd be all set and ready, to proceed
at a much higher speed (oh, and did I mention, that Zooming comes basically "for free"? ).

As for Controls, there's a nice set already implemented in vbWidgets.dll (Download-Link
is on vbRichClient.com) - but implementing your own is also not that difficult - their
internal Code is matching roughly with the philosophy I used with the VB-UserControl-Alpha-Demo,
it's just that you have much more powerful Events internally (compared to what's available
in a VB-Usercontrol).

Here's the Code for a (very) simplified Button-Widget, which is not dependent on the cwButton-Class
of the vbWidgets.dll-Project, but using only the Theming-Engine which is already in the BaseDlls of the RC5:

Option Explicit

'************ default-conventions, needed in any cwWidget-Class ************
Private WithEvents W As cWidgetBase
 
Private Sub Class_Initialize()
  Set W = Cairo.WidgetBase
End Sub

Public Property Get Widget() As cWidgetBase: Set Widget = W: End Property
Public Property Get Widgets() As cWidgets: Set Widgets = W.Widgets: End Property
'**************** end of default-conventions for cwClasses ****************

Private Sub W_MouseDown(Button As Integer, Shift As Integer, ByVal X As Single, ByVal y As Single)
  W.Refresh
End Sub
Private Sub W_MouseEnter(ByVal MouseLeaveWidget As vbRichClient5.cWidgetBase)
  W.Refresh
End Sub
Private Sub W_MouseLeave(ByVal MouseEnterWidget As vbRichClient5.cWidgetBase)
  W.Refresh
End Sub

Private Sub W_Paint(CC As vbRichClient5.cCairoContext, ByVal xAbs As Single, ByVal yAbs As Single, ByVal dx_Aligned As Single, ByVal dy_Aligned As Single, UserObj As Object)
Dim State As Long
  State = IIf(W.Root.MouseKeyDown And W.MouseOver, 1, 0) Or IIf(W.MouseOver, 2, 0)
  W.Root.Cairo.Theme.DrawTo CC, W, thmTypeButtonFace, State, 0, 0, dx_Aligned, dy_Aligned, 2
  CC.SetLineWidth 1
  W.Root.Cairo.Theme.DrawTo CC, W, thmTypeBorder, State, 0, 0, dx_Aligned, dy_Aligned, 2
  W.SelectFontSettingsInto CC
  CC.DrawText 1, 1, dx_Aligned, dy_Aligned, W.Key, , vbCenter, 2, True
End Sub

Really not much to code, to make your own fully alpha-aware Controls, which in conjunction
with the cWidgetForms will work flickerfree.

Olaf