Likewise don't assume i don't understand the usage/usefulness of double buffering. The only real usage for this is for images recieved through sockets or files read with bread.
Again, you're assuming that the binary variable is set once and never changed. This is the exact opposite usage for binvar support. The benefit is the ability to change the image directly in memory many times.
I'll make it easy and just show you an example, and you tell me if my usage is not "real":
; Assuming /drawcopy is modified to accept binvars as the input arg
; Draws and moves a square programmatically with double buffering
alias drawanim_1 {
bset &bvar 1 1 1 1 0 0
bset &bvar 6 1 0 1 0 0
bset &bvar 11 1 1 1 0 0
hadd anim buffer &bvar
.timerANIM 1 0 drawanim_2
}
alias drawanim_2 {
bset &bvar 1 0 1 1 1 0
bset &bvar 6 0 1 0 1 0
bset &bvar 11 0 1 1 1 0
hadd anim buffer &bvar
.timerANIM 1 0 drawanim_3
}
alias drawanim_3 {
bset &bvar 1 0 0 1 1 1
bset &bvar 6 0 0 1 0 1
bset &bvar 11 0 0 1 1 1
hadd anim buffer &bvar
.timerANIM 1 0 drawanim_1
}
; Main call to buffer / draw
alias drawanim {
drawanim_1 | ; Start buffering
.timerANIMTIMER 0 0 drawanim_timer
}
; Copy buffer to window
alias drawanim_timer {
noop $hget(anim,buffer,&bvar)
; 0 0 5 3 represents the expected dimensions of the
; contents in the binvar since there's no other
; explicit way to specify it.
drawcopy &bvar 0 0 5 3 @win 20 20 5 3
}
Note that I can do anything with those bvars, I'm not limited to statically defined data like in my example. You could for instance draw spirals of user defined size, or plenty of other dynamic drawing operations.
The usage here is exactly similar to buffering to a hidden @window and /drawcopying it to the actual window-- but the benefit is that a) you need no second window and b) mIRC doesn't need to go through the entire GDI layer just to draw image data, which is silly.
Convenient? Yes. Far more efficient? Yes. Can it be done with anything else? Only /drawcopy (see efficiency). Easy to implement? It pretty much already is (see /drawcopy). Is there more use than just sockets and files? ..Just look up. Priority? Maybe not, but the fact that it's "pretty much already implemented" trumps any issue of priority imho- it would be about half a day's work. Instead of BitBlt'ing from a HWND you just take the data from the *already existing* memory space.. implementation done. I don't get what the issue is here.
