Henrik Brix Andersen writes:
> It would be nice if someone on say... win32 ;)... would have a go at > writing the missing win32 part of the select_window() function.

I get the hint ;-). I'll have a look at it.

Grabbing the whole screen with screenshot (without any Win32 specific code yet) was *much* slower than with winsnap. It was the image transfer phase from the plug-in to GIMP that was a lot slower. I tried to change the code to just call gimp_pixel_rgn_set_rect() once, like winsnap does, instead of calling gimp_pixel_rgn_set_row() in a loop. And it is now much speedier. Do you see any reason why this should not be done? (Maybe also call gimp_tile_cache_size(), although calling it like winsnap.c does results in black screendumps, oddly enough.)

> When the win32 specific part of select_window() has been written and > committed I plan to retire the win32 specific winsnap plug-in in favor > of the new screenshot plug-in.

BTW, shouldn't it be possible to write select_window() using only GDK? gdk_pointer_grab() and, hmmm, well I'll think about it.

--tml

(Wonder why it seems to take so long for messages to go through gimp-developer@lists.xcf.berkeley.edu. Two or three days. Sobig.F?)

Henrik Brix Andersen writes:
> Using gimp_pixel_rgn_set_row() may work for some images, but since > GdkPixbufs internally have aligned data which may result in padding > garbage inserted between two rows, you will need to use > gdk_pixbuf_get_rowstride() and iterate over the rows one by one.

But couldn't one at least check if gdk_pixbuf_get_rowstride() indicates that there isn't any padding, and in that case use gimp_pixel_rgn_set_rect()? At least on my aging PIII-450, the difference in speed is huge.

> Unfortunately this doesn't seem to be possible. Believe me, I've tried > :(.

OK, I believe you...

--tml

Hi,

Tor Lillqvist writes:

Henrik Brix Andersen writes:
> Using gimp_pixel_rgn_set_row() may work for some images, but since > GdkPixbufs internally have aligned data which may result in padding > garbage inserted between two rows, you will need to use > gdk_pixbuf_get_rowstride() and iterate over the rows one by one.

But couldn't one at least check if gdk_pixbuf_get_rowstride() indicates that there isn't any padding, and in that case use gimp_pixel_rgn_set_rect()? At least on my aging PIII-450, the difference in speed is huge.

I am surprised that this makes any noticeable difference and I think it would be worth to check the reason for this. A much simpler optimization would probably to set a reasonable tile_cache size. At the moment the new screenshot plug-in fails to do that.

Sven

On 7 Sep 2003, Sven Neumann wrote:

Date: 07 Sep 2003 13:17:47 +0200
From: Sven Neumann
To: Tor Lillqvist
Cc: "gimp-developer@lists.xcf.berkeley.edu"
Subject: Re: [Gimp-developer] Screenshot plug-in status

Hi,

Tor Lillqvist writes:

(slightly Offtopic and delayed reply)

While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP.

Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard. Could pasting from the system ClipBoard be setup in such a way as to allow me to directly paste screenshots without needing to take the extra few clicks to Aquire from clipboard or use the Screenshot plugin?

Should I file an enhancenment request in bugzilla?

- Alan H.

On 10 Sep 2003 at 20:18, Alan Horkan wrote:

While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP.

This works perfectly for me with GIMP 1.2 and 1.3. I assigned shortkeys to the corresponding menu options in the Edit menu.

Michael

Hi,

"Michael Schumacher" writes:

While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP.

Perhaps you should use GNOME then ;)

Sven

At 20:18 10.09.03 +0100, Alan Horkan wrote:

While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP.

Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard.

Which you never tried at least _once_ before complaining ?

Though from the users point of view there may be no differnce between 'Copy' (== here Program internal and fast) and
'Copy from Clipboard' (== system global, data across process boundaries, kind of slow) [Available from File/Acquire (creating new) and /Edit/Paste from Clipboard pasting into current image. ]

From the developers point of view there is. [If it's still unclear, the

later is the one you are asking for. And it exists for years.]

Could pasting from the system ClipBoard be setup in such a way as to allow me to directly paste screenshots without needing to take the extra few clicks to Aquire from clipboard or use the Screenshot plugin?

Huh? May I suggest a hot key : ctrl-alt-ins ?

Should I file an enhancenment request in bugzilla?

Or better ctrl-alt-del ...

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

On Thu, 11 Sep 2003, Hans Breuer wrote:

Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard.

Which you never tried at least _once_ before complaining ?

I think you have misunderstood me. I used it many times, it works and I use what is available. I only mention it now because changes are being made to the screenshot code and perhaps there might be a better way to do screenshots and streamline the workflow.

Though from the users point of view there may be no differnce between 'Copy' (== here Program internal and fast) and
'Copy from Clipboard' (== system global, data across process boundaries, kind of slow)

I am aware that the system clipboard is different and slower, but isn't the real performance loss is from the user point of view.

I only ask that you take a moment and consider if there might be a way to make things faster for the user which is where speed really counts. Could some of the handling of the system clipboard be done automatically and only when needed to mitigate the speed tradeoff? If is impractical fair enough, I was just asking because the code was being changed anyway.

- Alan

On Thu, Sep 11, 2003 at 06:49:42PM +0100, Alan Horkan wrote:

I only ask that you take a moment and consider if there might be a way to make things faster for the user which is where speed really counts. Could some of the handling of the system clipboard be done automatically and only when needed to mitigate the speed tradeoff? If is impractical fair enough, I was just asking because the code was being changed anyway.

It should work that way but I haven't been able to build The GIMP to check for ages now.

To be completely clear: Edit/Cut, Copy and Paste _ought_ to transparently work between applications. The image-related KDE apps get this right and when GIMP 1.3.x devel code is once again up and running on this system I will ensure that it works properly in the GIMP too.

You are quite right that none of this costs _any_ significant resources until it's actually used to do what the _user_ wants. Which means it is unquestionably the Right Thing.

Nick.

On 11 Sep 2003, Sven Neumann wrote:

Date: 11 Sep 2003 02:04:24 +0200
From: Sven Neumann
To: Michael Schumacher
Cc: "gimp-developer@lists.xcf.berkeley.edu"
Subject: Re: [Gimp-developer] Screenshot plug-in status

Hi,

"Michael Schumacher" writes:

While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user.

Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP.

Perhaps you should use GNOME then ;)

I do use Gnome, just not all the time.

- Alan

On Thu, 11 Sep 2003, Alan Horkan wrote:

I only ask that you take a moment and consider if there might be a way to make things faster for the user which is where speed really counts. Could some of the handling of the system clipboard be done automatically and only when needed to mitigate the speed tradeoff? If is impractical fair enough, I was just asking because the code was being changed anyway.

It seems to me that using the system clipboard, but using the internal cut and paste instead of the system functionality whenever it is detected that the sender and reciever are the same process would be the best solution.

Rockwalrus

From: Alan Horkan
CC: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Screenshot plug-in status Date: Thu, 11 Sep 2003 18:49:42 +0100 (BST)

On Thu, 11 Sep 2003, Hans Breuer wrote:

Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard.

Which you never tried at least _once_ before complaining ?

I think you have misunderstood me. I used it many times, it works and I use what is available. I only mention it now because changes are being made to the screenshot code and perhaps there might be a better way to do screenshots and streamline the workflow.

Though from the users point of view there may be no differnce between 'Copy' (== here Program internal and fast) and
'Copy from Clipboard' (== system global, data across process boundaries, kind of slow)

I am aware that the system clipboard is different and slower, but isn't the real performance loss is from the user point of view.

I only ask that you take a moment and consider if there might be a way to make things faster for the user which is where speed really counts. Could some of the handling of the system clipboard be done automatically and only when needed to mitigate the speed tradeoff? If is impractical fair enough, I was just asking because the code was being changed anyway.

well, i am very happy with the way GIMP's clipboard and buffers are kept separated from the win32 clipboard, i frequently keep text lying around in the win32 clipboard that i may well use frequently, but i very rarely need to copy image data outside of the GIMP, and this way i can have all my named buffers, i can cut and paste between GIMP images while keeping my text in the clipboard for use in text editors and web browsers, handy if you're multitasking.

so, on to screenshots, i sometimes use alt-printscrn and acquire, but more often acquire screenshot, as that way i don't nuke the contents of the clipboard.

i may have completely missed the point here, but i think keeping clipboard functions the way they are and maybe adding a paste as new from clipboard function along with the others so that acquire doesn't have to be used every time.

Phil.

- Alan

Alan Horkan writes:
> I was just asking because the code was being changed anyway.

Well, actually it's not certain at all that the screenshot code used on Win32 will be changed. The winsnap plug-in works, and even if code from it was copied into screenshot.c, it wouldn't still work the same way as on X11 (i.e., you still would have to select the window to grab by dragging the mouse and release the button when on top of the target window, not just move the mouse and click when on top), so why bother... Additionally the winsnap code requires currently an .rc file, and taking care of that in plug-ins/common/Makefile.am would cause additional pain.

(Making it work like on X11 would require some pretty hairy changes to the way GDK mouse grabs are implemented on Win32 (and keyboard grabs while at it), won't presumably happen soon. See my post on gtk-devel-list.)

--tml

Hi,

Nick Lamb writes:

It should work that way but I haven't been able to build The GIMP to check for ages now.

To be completely clear: Edit/Cut, Copy and Paste _ought_ to transparently work between applications. The image-related KDE apps get this right and when GIMP 1.3.x devel code is once again up and running on this system I will ensure that it works properly in the GIMP too.

Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice.

Sven

Hi,

Tor Lillqvist writes:

Additionally the winsnap code requires currently an .rc file, and taking care of that in plug-ins/common/Makefile.am would cause additional pain.

This argument is nil since we can always move screenshot to it's own subdirectory.

I was hoping that there was interest in getting rid of (almost) all differences between platforms and doing a common screenshot plug-in would be one more step towards this goal. Sad to hear that you prefer to keep the winsnap plug-in alive.

Sven

I was hoping that there was interest in getting rid of (almost) all differences between platforms and doing a common screenshot plug-in would be one more step towards this goal. Sad to hear that you prefer to keep the winsnap plug-in alive.

Well yes, that is a good goal. But as it started to seem that the "common" screenshot plug-in would still need to contain a lot of the Windows-specific code from winsnap.c (i.e., not just a short code snippet inside one function like for X11), I just thought it wouldn't be worth the effort.

--tml

On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote:

Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice.

Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there. X content negotation lets us change our minds later, and GIMP's plug-in architecture lets us make this modular if we decide that's necessary...

Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side?

Nick.

Hi,

Nick Lamb writes:

Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there.

Sorry, but what is, in your opinion, the de facto standard?

Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side?

It would break the feature freeze but since we aren't yet handling the freeze very strictly and since we actually wanted to have this in 2.0, a clean patch that arrives before the end of the month could probably still be considered.

Sven

Nick Lamb wrote:

On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote:

Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice.

I had hoped to spend time on this before 2.0 pre1, but that's not going to happen now. And it does kind of break the feature freeze. But it shouldn't be a huge packet of code.

Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there. X content negotation lets us change our minds later, and GIMP's plug-in architecture lets us make this modular if we decide that's necessary...

I'm not aware of any de facto standard - how does kde pass image data around? The only clipboard standard I know of is the one on freedesktop which says "Explicit copy -> use SECONDARY", and keeps the selected buffer = PRIMARY as an easter egg which isn't really going to be used much in future.

There is no standard for image data interchange that I know of, and I did have a look.

Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side?

That's a fairly big assumption :) 2.0 pre 1 (which will be absolutely string & feature frozen to give translators, documentors and the like time to clean up before 2.0) is planned for a fortnights time. There are only 2 or 3 blockers left for that release, and they're all pretty small. So the spirit of Free Time is the biggest problem I see with it :)

It would be nice if we did this in a way which would interoperrate with other apps, though - which is why using image/png is so attractive. Even if we were to use something else between different gimp instances, we get to communicate with everyone who understands png.

As to freedesktop, as I said I'm not aware of any standard (de facto or otherwise) - I had planned to write up a proposal to use as the basis of a freedesktop proposal after 2.0 pre1 gets out the door. But if you implement something in the meantime, there shouldn't be any problem getting it in, as long as it's feature complete and fairly clean (as Sven said).
Cheers,
Dave.

Hi,

David Neary writes:

That's a fairly big assumption :) 2.0 pre 1 (which will be absolutely string & feature frozen to give translators, documentors and the like time to clean up before 2.0) is planned for a fortnights time. There are only 2 or 3 blockers left for that release, and they're all pretty small.

If your plan is to do a complete string freeze, I see a couple more than 2 or 3 blockers. But yes, we should try to avoid changes to translatable messages when the time has come for the prereleases.

Sven