AutoHotkey Community

[Terrapin]

I worked on several ideas for creating a border around the selected window (selected with TAB as in a z-order). I came up with this, but I'm afraid it may slow things down? It is difficult for me to tell how much. I am just checking back since I last posted, so I haven't tried the newer scripts.

I'm just going to post my code, and the only other of mine is one line, right before the timer starts:

[majkinetor]

Are you Bob or are you Terrapin ?
_________________

[Terrapin]

majkinetor:

[majkinetor]

3thd approach

For this AHK will not be enough since I will use system hooks (maybe one day in AHK)

This thing can be made real time if we create thumbnails on TOP LEVEL window activation and destroy them on window close. So, we will have the picture ready for display at any time. This will introduce very low system performance loss cuz of nature of activation but the display part would be instantious.

I didn't find anythihg useful yet for the real time preview of window contest...
_________________

[holomind]

what about bitblitting or xor-ing a border for the selection. we already have a formular for the coordinates. there are some nice gdi functions we could use to modify the dc (virtual-bitmap) would be a lot faster than winset region i think. also no additional gui is needed. the nice thing with xor is that if you apply the same function twice its reversed to the original state. xor would invert the colors. i you have a small black border around the windows it could be made white ...
or one simpyl draws rectangles with a "brush" (i think msdn calls them this way) and remove it later. or even much cooler simply zoom the window with strechblit (wouldnt be too fast).
i tried a bit to store the dc into a virtual buffer so the thumbnails could be stored until the next show:gui of expose but i didnt manage it yet.
a hard way would be to store the screenshots a real images (bmp/png) and load them back into the gui.

ooh, and some time i need to merge all the changes back into first post. we should use subversion or cvs to work on the same copy in realtime

[Terrapin]

I have corrected and cleaned up some things in my code, and now the border which shows 'focused' thumbnail looks very cool. I don't think it slows down anything, other than a millisec or so. I'd be happy if someone looked at it. I've been working with the version Da0nlyfreez posted. I think it could be inserted fairly easily into any version.

There are 'phantom' windows, I haven't investigated why, maybe they are excluded, maybe just dropped. But upon activation, the active window is now usually the focused thumbnail. When it is not, I *think* it is due to trying to focus on a thumbnail which does not exist.

Either type of selection (click or press enter) works fine, all the time, as far as I can see. I could add shift-tab... whatever. I may add back the window numbers, but not sure they are necessary.

Thanks for hearing me.

[SanskritFritz]

[majkinetor]

[Laszlo]

[holomind]

the artefacts only come from the usage of printwindow() which we use in a very fast way. perhaps also the time when the dc is relased has some effects. i noticed bigger artefacts in IE und FF in their browser renering engine, also i get more black frames when i use topdesk at the same time as this programm grabbs some printwindows at the same time ?!
grabbing the frontwindow with bitblt never gave me artefacts. perhaps its internal with the way windows-os refreshes windows. and if you just a second before painted it with printwindow() it believes there is no need to repaint again (but it was another user/gui

in terms of speed there is a noticable difference in using strechblt with antializing or not. but without antializing the quality is below usable. as this is all bits and bytes i thought if it would be faster if strechblt is a fracton of the screen like half, quarter etc. would this be faster than odd numbers like 5 ?

the idea to draw all thumbnails on an uber-big screen and then resize them all at once sound nice, but as much as i understand the gdi documentation bitblt only works on the visible screen, so you also cant make a screenshot from printwindow which is bigger than your screen (monitorsize). i hope i am wrong because then i could build some nice virtual-destop manager etc.

my plan is to extract the core gdi calls into a library and make then easy to use. so one could build something like expose, deskman, lifewindows, screenshot (a portion) to bmp or thumbnail, etc. without knowing the bits and bytes of gdi and msdn. ... i like to have a core engine which takes the thumbnails in regular intervalls and buffers them and then one can use this dc-buffers when needed to build some fancy things which are announced for windows-vista or os/x. also i like to find a way to use opengl or directx in a similar way i use gdi now, and do some animations. i know there are basic lanuages out there allowing easy access to directx. but i like to do it directly. for some simple effects. (not programming games, but litte ahk-tools...) eg. screenshot from video with help of direct-x etc.

[Laszlo]

I found a potential problem: the original script first activated the selected window and only closed the GUI afterwards. It is safer to do it the other way. I could reduce WinDelay to 0 this way, and still got stable behavior. The slight speed improvement is probably not noticeable, but in my PC the script is stable.

[majkinetor]

yes, that might be the problem.
Also, we can call InvalidateWindow after instead to minimize and restore the affected window, so really no problem with this...
Also, no problem with "expose" title (pointed by Sans), since gui hwnd will be used instead.

I think that shrinking after aranging all will lead to noticable speed improvement. I really don't know if windows can be screenshoted if they are out but I have positive experience with IE window. In my application HtmlToImage I succesifully converted html page to image, without restrictions on screen size... for instance, if page was 100 pages long, you would get 100MB "long bitmap"... The only problem is that I was using COM to get this. I was simply tellilng IE to give me desired rect of his DC without restrictions of any kind...

I beleive this is possible anyway...
_________________

[holomind]

@lazlo: i put your latest version into the first post, also the downloadable expose.ahk is the latest version.

@majkinetor: sounds good if bitblt / dc is not limited by screensize, this would give many new posibilites for new applications. hopefully this is only limited by the memory of your graphicscard. i guess dc is not stored in real memory by directly in gfx-card and hardware accellerated.

one way to "store" the images would be to paint them "offscreen" on the big dc and copy them to the visible area with bitblt or strechblt when needed. they could be stored in minimized version already so one can use bitblt instead of strechblit which is much faster.

also this would allow first experiments with animating the windows and slide them in and out. having the backbuffer in the invisible region of the dc.
animations should be possible as i manage to get 10 or more frames per second using my magnifier which constantly copyies the window with bitblt, so animatig the windows and sliding them with about 5 frames / sec would be possible even without directx. (is quite cpu intensive and directx would be faster i quess) as i have a shared memory card (intel-notebook) i cant decide between cpu und gfx-cpu (gpu) also memory -usage is shared. so if you have "real" grahics card like ati it might be different.

[holomind]

[holomind]

Looking at laszlos code