Anders Melander

It does. You just need to keep the attribution, copyright and license notice in the source.

I tried with a 5500x4000 bitmap and I did actually manage to produce some lag. I then changed the resampler to TDraftResampler and the lag was completely gone. Same with TNearestResampler.

Did you set ImgView.RepaintMode=rmOptimized ? Try to set a breakpoint in line 2380 of GR32_Image ("SourceRect := GetBitmapRect;") to verify that the correct version is being used. Can you reproduce the problem with the small example that I posted earlier (remember to make the changes I later mentioned and set RepaintMode):

Nicklaus Wirth disagrees: https://en.wikipedia.org/wiki/Wirth's_law Bonus quote: What Intel giveth, Microsoft taketh away: https://en.wikipedia.org/wiki/Andy_and_Bill's_law

The design time functionality hasn't changed so you don't need to recompile the packages. The easiest way to test it out would be to just copy the modified GR32_Image.pas to the source folder of your application. That way your application will compile with the new GR32_Image but your existing Graphics32 installation will not be affected. Once the changes are merged into the main Graphics32 branch you can update your Graphics32 installation and remove the local copy of GR32_Image.

@wadepm Here's the branch with the optimized scroll: https://github.com/graphics32/graphics32/tree/TImgView32_optimized_scroll Note that the optimization only comes into play if you're not using the rmFull repaint mode (see TImgView.RepaintMode). Give it a spin!

Well, I couldn't resist the challenge so I have a nicely working implementation now. I'll create a pull request with it tonight (it's 6 in the morning here in Denmark) when I wake up again .

I think TLinearKernel (or just the TLinearResampler) will yield the best down-sample quality with good performance. The links I posted explains why. The update mechanism redraws the areas of the bitmap that changes. When you pan the bitmap doesn't change but the view of it does. Therefore the optimized update can't handle the pan so the whole viewport is repainted instead. I'm currently investigating if I can shoehorn a pan optimization into the existing framework with minimal changes. That's what I do when previewing large bitmaps (for PixelFormat=pf32bit) but I only do it do avoid out of memory: // Get RGBA from source ImageView.Bitmap.BeginUpdate; try // Limit preview image size const MaxPixels = 1024*1024; var Pixels := TBitmap(FImage).Width * TBitmap(FImage).Height; if (Pixels >= MaxPixels) then begin var Scale := Sqrt(MaxPixels / Pixels); // Proportionally scale bitmap so the result doesn't contain more than the desired number of pixels ImageView.Bitmap.SetSize(Round(TBitmap(FImage).Width * Scale), Round(TBitmap(FImage).Height * Scale)); // Stretch draw the source bitmap onto the scaled bitmap TBitmap(FImage).Canvas.Lock; try SetStretchBltMode(ImageView.Bitmap.Canvas.Handle, COLORONCOLOR); ImageView.Bitmap.Draw(ImageView.Bitmap.BoundsRect, TBitmap(FImage).Canvas.ClipRect, TBitmap(FImage).Canvas.Handle); finally TBitmap(FImage).Canvas.Unlock; end; end else begin ImageView.Bitmap.SetSize(TBitmap(FImage).Width, TBitmap(FImage).Height); for var Row := 0 to TBitmap(FImage).Height-1 do MoveLongword(TBitmap(FImage).ScanLine[Row]^, ImageView.Bitmap.ScanLine[Row]^, TBitmap(FImage).Width); end; finally ImageView.Bitmap.EndUpdate; end; ImageView.Bitmap.Changed;

If the TStrings.Objects isn't used for anything then, instead of separating the strings and checked states into two list and then sort both simultaneously, you could just stuff the checked state into TStrings.Objects and then use the standard TStrings.Sort. Or you could sort a TList<integer> of indices, using TList<>.Sort and then reassemble the sorted string list based on the result.

Less questions. More autonomy.

It's sampling every time it draws something. That doesn't mean that it necessarily resamples the whole bitmap though. It will only sample the parts that it needs in order to paint the visible part of the bitmap. Read this: https://graphics32.github.io/Docs/Additional Topics/Sampling and Rasterization.htm https://graphics32.github.io/Docs/Additional Topics/Repaint Optimization.htm Of course when scale < 1 then the whole bitmap will probably be visible and everything will be sampled. As far as I remember there's no repaint optimization with regard to panning - I guess that's something I could look into if I run out of other stuff to do Anyway, even if you did pan 1 pixel at a time (which I doubt you're doing) it should be fast enough that you shouldn't experience any stutter. Of course it depends on the type of sampler/kernel you're using, your hardware and the size of the bitmap but on my old system I can pan a zoomed (in or out) 4000x4000 multi layer bitmap without any noticeable stutter.

It's not the look that's the problem. It's the usability. The DevExpress grid has both a preview pane and an in-place edit form feature. I'm referring to the edit form, I suspect you're referring the the preview pane. In-place editor form: Preview: That sounds more sensible to me. Like a property inspector. The problem with putting stuff into the grid is that is interferes with the nice overview the grid layout provides. Regardless it would still be a good idea to create a mockup before investing too much time on this.

I don't really know what type Source is but assuming it's a TBitmap32 then loading a PNG with LoadFromFile will internally use a TPicture to load the file and then assign the TPicture.Graphic (which will be a TPNGImage) to the TBitmap32 using a generic import routine that replaces the transparency with white. This matches what you're observing. As far as I can tell everything works "as designed". What did you expect this would do? If you want to display a 32-bit TBitmap with alpha using TImage then I suggest you create a 32-bit RGBA bmp file and experiment with getting TImage do display that. You have too many variable factors in your approach. Get one thing working first. Then move on to the next problem. The above has nothing to do with Graphics32.

You didn't answer my question: Have you verified that the transparent PNG pixels are still transparent after conversion to TBitmap32? As far as I can tell, from the 4 lines of code you posted, you're not really using graphics32 to draw anything here. If you draw a TBitmap32 onto a Windows GDI device (Image.Canvas.Handle) then the GDI StretchDIBits function will be used to draw it - hence no transparency. The primary reason to use graphics32 is that it allows you to do the composition (blending, merging, layers, rendering, etc) really fast and then draw the final image onto the screen. If what you actually want is to draw something onto the screen with transparency then maybe you shouldn't be using graphics32 at all? If you really want to draw a TBitmap32 onto a GDI device with transparency then you should assign it to a TBitmap, set TBitmap.AlphaFormat=afDefined and then draw the TBitmap instead. TBitmap will use the AlphaBlend function in this case. var Bitmap := TBitmap.Create; try Bitmap.Assign(Bitmap32); Bitmap.AlphaFormat := afDefined; Bitmap.DrawTo(Image.Canvas.Handle, 0, 0); finally Bitmap.Free; end; Btw, are you really sure you want to draw onto the TImage.Canvas? That seems.... um... like a mistake...

Maybe you should make a proof of concept using a DevExpress trial first and have your users test it. We use DevExpress grids and have that feature enabled on a few of them and the users hate it. It looks like a good idea but the usability sucks. Maybe that's just the way DevExpress has implemented it though.

I don't use LoadBitmap32FromPNG and it's not part of Graphics32. Have you verified that the transparent PNG pixels are still transparent after conversion to TBitmap32? Other than that the problem could be the blend and combine mode used when drawing but that should be the same regardless of the origin of the pixel data.

Yes. That was just a brain fart on my behalf.

Well that was easy. Luckily the bug was in my own code. Here's the code that works: procedure TFormMain.ImgViewMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer; Layer: TCustomLayer); begin if (Button = mbLeft) then begin FPanning := True; ImgView.Cursor := crSizeAll; FStartPos := Point(X, Y); end else if (Button = mbMiddle) then ImgView.Scale := 1; end; procedure TFormMain.ImgViewMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer; Layer: TCustomLayer); begin if (not FPanning) then Exit; var NewPos := Point(X, Y); var Delta := FStartPos - NewPos; FStartPos := NewPos; if (Delta.X <> 0) or (Delta.Y <> 0) then ImgView.Scroll(Delta.X, Delta.Y); end;

Reproduced. I've actually encountered that problem in my own applications but I've never been able to pinpoint the circumstances that surfaced the problem. I'll investigate now.

My guess is that you're using the wrong TImgView32.ScaleMode. Make sure TImgView32.ScaleMode=smScale. I've attached a small example that demonstrates how to pan and zoom with TImgView32. imgview32demo.zip

Do you sell your software? Are there bugs in it? How do you sleep at night? I guess I don't understand what your point is.

Instead of terminating the application in the debugger you can pause it and then examine the call stack to see what the application was doing.

Nope. A rewrite of an old, large and complex system is not something that you just do. The history and literature is full of examples why. Remember Netscape, Lotus 123, etc.?

As you've probably discovered then only difference between having the TActionList on a form and having it on a datamodule is that the shortcuts isn't processed. You can see why in TCustomForm.IsShortCut. As far as I can see you can solve that by simply calling TActionList.IsShortCut from your forms OnShortCut event handler. Apart from that, as @PiedSoftware wrote, the TAction.OnUpdate event only gets called when the action isn't suspended and the associated control(s) becomes visible. For example if you have an action linked to a menu item then the action is only updated when the sub menu that contains the menu item is shown. If you have an action linked to multiple controls then the action is updated if just one of them is visible. A classic goof is to update the actions Visible property in the OnUpdate handler and then wondering why the action isn't updated anymore - it's because the associated control has been hidden and hidden control don't cause the action to update. Also if you use the TActionList.OnUpdate handler be aware that it's called once for each and every action in the list. If you just want an OnUpdate handler that called once for every "cycle" then you can create an action and assign it to the form and use that actions OnUpdate instead. You will have to control the form caption through the action though.

Yes that seems to be it; TImgView32 adds scrollbars and methods to scroll and center the image.