 |
AutoHotkey Community Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
tic
Joined: 22 Apr 2007 Posts: 1375
|
Posted: Thu May 22, 2008 10:28 am Post subject: |
|
|
Cool. It worked. Had to guess the enumeration (havent got the sdk installed) and couldnt find it, but theres only 2 options anyway!
over = 0
copy = 1
Thanks again Lex. This means its not necessary to have many guis now due to ahks slowness  |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 2739 Location: Australia, Qld
|
Posted: Thu May 22, 2008 11:33 am Post subject: |
|
|
It is defined on MSDN as CompositingMode. Once you know that enumerations in C++ begin at zero by default, there is no need for guesswork.
| tic wrote: | | ...due to ahks slowness | GDI+ is the bottleneck... |
|
| Back to top |
|
 |
tic
Joined: 22 Apr 2007 Posts: 1375
|
Posted: Thu May 22, 2008 1:45 pm Post subject: |
|
|
i think the main bottleneck is actually ahk. For instance whenever I want to do a loop with anything then c# does it like a million times faster (may be an exaggeration) for example take a look at the code for working out which button the user is hovering over. i had to optimise it for speed as the original version was much too slow (but then this version becomes complex and hard to easily change)
So basically the slowness I'm talking about is the stuff to do with ahk that is slow.... |
|
| Back to top |
|
 |
tic
Joined: 22 Apr 2007 Posts: 1375
|
Posted: Thu May 22, 2008 2:11 pm Post subject: |
|
|
Oh man.....it doesnt seem feasible using this method rather than many guis...
UpdateLayeredWindow seems to be soooo slow to update the entire gui. Can just the correct area be updated rather than the whole window?
Edit:
This is very unusual. Further testing has shown that actually its very fast (faster than with many guis) except when i set the size to be 0.3x the size of the original bitmaps??
Its faster when its larger and faster when its smaller....mmmm
Edit2:
For UpdateLayeredWindow:
| Quote: | psize
[in] Pointer to a SIZE structure that specifies the new size of the layered window. If the size of the window is not changing, psize can be NULL. If hdcSrc is NULL, psize must be NULL. |
But when i dont want to update its width or height and try:
Then i get return code 0 and it does nothing. What type do i need to specify for it to work?
works for the structure but i dont want to update its size.
Thanks |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 2739 Location: Australia, Qld
|
Posted: Fri May 23, 2008 1:07 am Post subject: |
|
|
This:should be the same as this:which I have used in the past.
| tic wrote: | | i think the main bottleneck is actually ahk. | I've tried a few times to use GDI+ from C# for real-time applications, but have inevitably given up and moved to Direct3D because GDI+ was way too slow. The overhead of AHK generally isn't that significant. |
|
| Back to top |
|
 |
LuceGold Guest
|
Posted: Thu Jun 26, 2008 10:17 pm Post subject: |
|
|
Lexikos, this may be off the beaten path of this thread, but can, or better yet, can I use GdipCreateBitmapFromStream with alpha-blending to render & overlay (2) incoming pStreams into a single composite bitmap somehow?
....theory like
| Code: |
DllCall("gdiplusGdipCreateBitmapFromStream", UInt,pStream,UIntP,bitmap1)
DllCall("gdiplusGdipCreateBitmapFromStream", UInt,pStream,UIntP,bitmap2)
...
GDIplus_SaveImage(joined_bitmap, OUTPUT, "IMAGE.PNG", encoderParams)
|
something like this even possible? |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 2739 Location: Australia, Qld
|
Posted: Fri Jun 27, 2008 7:16 am Post subject: |
|
|
| Yes - Create a bitmap to draw into (and Graphics object to draw with), then draw each input bitmap onto it. |
|
| Back to top |
|
 |
LuceGold Guest
|
Posted: Fri Jun 27, 2008 9:12 am Post subject: |
|
|
I am sorry Lexikos, I am not a true expert *(yet), I hope to be.... but could you --please-- show me a basic example that I could work with? Nothing fancy, but just the ability to layer over 1 image over another in any arbitrary spots as a saved PNG. I would be most appreciative here.....
I've gotten pretty handy with GDI, but still not 100% clear on all the syntaxes, and how to flow control the bitmaps, etc  |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 2739 Location: Australia, Qld
|
Posted: Fri Jun 27, 2008 9:42 am Post subject: |
|
|
| Perhaps tic's GDI+ standard library and examples may help. In particular, the fifth example is similar to what you're asking for. |
|
| Back to top |
|
 |
tic
Joined: 22 Apr 2007 Posts: 1375
|
Posted: Fri Jun 27, 2008 10:16 am Post subject: |
|
|
Yes refer any questions to that topic
You would need to get 2 gdi+ bitmaps (pBitmap) of your 2 images, and then you will Gdip_DrawImage twice, with the second 1 having a lower transparency:
| Code: | | Gdip_DrawImage(G, pBitmap, dx, dy, dw, dh, sx, sy, sw, sh, 0.5) |
with 0.5 being 50% transparency.
I just added credit to you on that topic Lexikos. I was planning to completely do the whole library before adding credits etc, but it's pretty much finished I think apart from commenting... |
|
| Back to top |
|
 |
LuceGold Guest
|
Posted: Fri Jun 27, 2008 10:21 am Post subject: |
|
|
Cool, thanks gentlemen! I will try this out, and check into the topic. I think I can figure this one out ... hopefully Have a very good day |
|
| Back to top |
|
 |
dajuha
Joined: 19 Oct 2007 Posts: 3
|
Posted: Sun Aug 03, 2008 11:53 pm Post subject: |
|
|
Has anyone found a solution to his question? Using a timer to preserve the z-order causes flickering. I've done my best to find a solution without any luck.
| tic wrote: | mmm whats going wrong here....
| Code: | OnMessage(0x46, "WM_WINDOWPOSCHANGING")
Gui, 1: -Caption +ToolWindow +0x400000 +LastFound
Gui1 := WinExist()
Gui, 1: Add, Text, x0 y0 w200 h200 Border Center gMove, Drag
Gui, 1: Show, x200 y200 w200 h200, Gui1
Gui, 2: -Caption +ToolWindow +0x400000 +LastFound
Gui2 := WinExist()
Gui, 2: Show, x150 y150 w100 h100, Gui2
Return
Move:
PostMessage, 0xA1, 2,,, A
Return
WM_WINDOWPOSCHANGING(wParam, lParam)
{
global
If (A_Gui = 1 && !(NumGet(lParam+24) & 0x2))
{
x := NumGet(lParam+8), y := NumGet(lParam+12)
Result := DllCall("SetWindowPos", "UInt", Gui2, "UInt", Gui1, "Int", x-50, "Int", y-50, "Int", "", "Int", "", "Int", 0x01)
}
SetTimer, OnTop, 10
Result := DllCall("SetWindowPos", "UInt", Gui1, "UInt", Gui2, "Int", "", "Int", "", "Int", "", "Int", "", "Int", 0x03)
;Tooltip, %Result%
Return
}
OnTop:
SetTimer, OnTop, Off
Result := DllCall("SetWindowPos", "UInt", Gui1, "UInt", Gui2, "Int", "", "Int", "", "Int", "", "Int", "", "Int", 0x03)
Return |
it shouldnt be necessary to set a timer, and makes it look messy, but why does correcting the z-order not work? obviosuly alwaysontop as shown in your example cannot be used, but then how would i keep the z-order? |
|
|
| Back to top |
|
 |
|
|
You can post new topics in this forum You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|