Prev: Find interactive user name / token (again) problems
Next: Time since wakeup?
From: Grzegorz Wróbel on 14 Jun 2008 15:09
Hi,

I am able to succesfully call MagSetImageScalingCallback() to set new
MagImageScalingCallback function, however my callback function gets
called only 2-3 times and it provides 4x4 pixel source data (with some
garbage instead source pixels). My source rectangle is 256x256 pixels.


Are there any sample how to use custom MagImageScalingCallback function?
Or is this part of Vista magnification API simply broken?

Or is it that this functionality is not implemented in all WDDM drivers?

--
Grzegorz Wr�bel
677265676F727940346E6575726F6E732E636F6D
From: Ivan Brugiolo [MSFT] on 16 Jun 2008 23:10
The MagXXX APIs in Vista are meaningful only when
milcore.dll is being used to produce a magnified view of the desktop,
that may or may not be the case in your specific configuration.
For most of practical usages, the image filtering callback is not
that interesting.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Grzegorz Wr�bel" </dev/null(a)localhost.localdomain> wrote in message
news:g32t8b$n2v$1(a)atlantis.news.neostrada.pl...
> Grzegorz Wr�bel wrote:
>> Hi,
>>
>> I am able to succesfully call MagSetImageScalingCallback() to set new
>> MagImageScalingCallback function, however my callback function gets
>> called only 2-3 times and it provides 4x4 pixel source data (with some
>> garbage instead source pixels). My source rectangle is 256x256 pixels.
>>
>
> Well, calling MagSetWindowSource() *before* MagSetImageScalingCallback()
> makes my own MagImageScalingCallback function to be called with correct
> pixel source data, however it still gets called only once.
>
> --
> Grzegorz Wr�bel
> 677265676F727940346E6575726F6E732E636F6D

From: Ivan Brugiolo [MSFT] on 19 Jun 2008 12:25
What you observed is consistent with the status
of the MagXXX apis in Vista.

Even with desktop composition OFF, if you are running at 8bpp,
the MilCore-based magnification path will not be executed.
With desktop composition-on or off, at 32, 24 and 16bpp,
the Milcore-based code-path will be used.
With desktop composition ON, window filtering will work,
but not image filtering callback.
With desktop composion OFF, window filtering will NOT work,
and image filtering will work.

`window-filtering` can work with composition-OFF using
private APIs that relay on layered windows, and only on layered windows.
This limitation cannot be fixed, and, will stay there.

When MilCore is being used, magnification.dll uses the same rasterizer
of WPF to produce the final to-be-displayed image.
For example, this allows you to supply a color transform, and have
the color transform to be imlemented by D3D9.L capable hardware.

When desktop compositon is ON, magnification.dll receives
a complete copy of the visual tree, and, it can apply transformation
and prune visual elements, so that window filtering can be implemented.

Most of these limitations will be addressed in the next version of the
operative system.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Grzegorz Wr�bel" </dev/null(a)localhost.localdomain> wrote in message
news:g38bpf$mns$1(a)nemesis.news.neostrada.pl...
> Ivan Brugiolo [MSFT] wrote:
>> The MagXXX APIs in Vista are meaningful only when
>> milcore.dll is being used to produce a magnified view of the desktop,
>> that may or may not be the case in your specific configuration.
>> For most of practical usages, the image filtering callback is not
>> that interesting.
>>
>
> In the "debug version" I do have the Vista magnification control visible
> on the screen. The successfully registered callback is called only once
> (or on some machines not at all).
>
> Since it was hard to believe that some Vista APIs might be broken, I
> thought that maybe it is that my graphic drivers that are not 100% WDDM
> compatible. But I asked few persons with different hardware configuration
> to run my code and they confirmed it that the registered magnification
> callback is called only once (or not at all).
>
>
> The most interesting fact is that this happens only when the DWM is on,
> when it's off then magnification callback works! Only that I don't need it
> to work with DWM off (especially that other magnification functions like
> MagSetWindowFilterList() will not work with DWM off), I need it to work
> with DWM on.
>
>
> So if something doesn't work in current Vista release maybe it would be
> worth to mention it in the documentation. ... Well the word
> "documentation" sounds too proud. If you look at MSDN entry about
> MagImageScalingCallback function:
> http://msdn.microsoft.com/en-us/library/ms692392(VS.85).aspx
>
> A child after few C++ classes will tell you a function declared like that
> has no right to compile. Even if you fix obvious typos it is still
> inconsistent with what I find in "magnification.h" from Windows Vista SDK.
>
> So all I have is the function declaration from magnification.h
> But that's apparently the declaration of a function that doesn't work.
>
>
> --
> Grzegorz Wr�bel
> 677265676F727940346E6575726F6E732E636F6D

From: Ivan Brugiolo [MSFT] on 20 Jun 2008 22:50
Windows NT 7.0, in your terminology.
What is the scenario why the Image Filtering Callback is interesting ?

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Grzegorz Wr�bel" </dev/null(a)localhost.localdomain> wrote in message
news:g3einj$pra$1(a)nemesis.news.neostrada.pl...
> Ivan Brugiolo [MSFT] wrote:
>> With desktop composition ON, window filtering will work,
>> but not image filtering callback.
>> With desktop composion OFF, window filtering will NOT work,
>> and image filtering will work.
>>
>> `window-filtering` can work with composition-OFF using
>> private APIs that relay on layered windows, and only on layered windows.
>> This limitation cannot be fixed, and, will stay there.
>>
>
> Lack of window filtering with DWM composition off is not that much of a
> problem, since with DWM composition off the display is working the same as
> on all pre-Vista Windows systems (where there was no Magnification API).
> And for now I hardly imagine any developers releasing software that has
> Windows Vista as minimum OS requirement.
>
> Not working filtering callback while DWM composition is on is a problem.
> For me it meant the decision of dropping support for Windows Vista (the
> code that works on pre-DWM displays doesn't work with DWM on).
>
>>
>> Most of these limitations will be addressed in the next version of the
>> operative system.
>>
>
> Does it mean Windows Vista SP2 or Windows NT 7.0?
>
> --
> Grzegorz Wr�bel
> 677265676F727940346E6575726F6E732E636F6D

From: Ivan Brugiolo [MSFT] on 23 Jun 2008 20:44
PrintWindow for Thumbnails is not supposed to work.
Thumbnails are alternate representation of the visual tree that are
drawn directly to the backbuffer, and, the do not share any state
with User or GDI. I would expect you to get back a window
with the default background brush.

I'd be surprised if PrintWindow were not to work for the
window hosting the magnifier.
Does this happen also for D3D9 applications ?
Does this happen for WPF applications ?
The magnifier window should be no
different than a 9L app or a WPF app.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Grzegorz Wr�bel" </dev/null(a)localhost.localdomain> wrote in message
news:g3pc25$2fs$1(a)nemesis.news.neostrada.pl...
> Ivan Brugiolo [MSFT] wrote:
>> PrintWindow should work with the window hosting
>> the magnification.dll child window.
>> However, the number of stept and copies of video-memory bits
>> would be insourmountable.
>>
>
> The last time I was checking it didn't work. Unless something has changed
> with SP1. I'd got the frames of the the host window, but the magnification
> control was blank. Same came for for calling PrintWindow() for thumbnails
> windows.
>
> Even if that has to cost I would rather have it, knowing it's an expensive
> operation, that not having it at all. After all it is the cost that comes
> "on demand" whenever PrintWindow() is called, ie just having it doesn't
> cost, using it costs. So I could decide if it's worth to pay that price or
> not, right now I don't have even that choice.
>
>> the current thinking is the following:
>> The image filtering callback will work, but, it will have all the
>> expensive
>> characteristics we've been describing.
>> Meaning: you will have to pay the cost of round-tripping the bits from
>> and to video-memory to allow a CPU-visible copy to be touchable.
>
> As stated above it's still better to have an expensive possibility than
> not having it at all. I will gladly pay the costs to be able to do
> something than stay with an alternative of impotency such as Windows Vista
> seems to offer in this area.
>
>> In terms of direction, the kind of customization you are trying to
>> achieve
>> is normally accomplished with variations of Thumbnails.
>> That is the only approach that has a reasonable chance to be performant
>> but, there are no plans to open-up that feature to further customizations
>> and having a meaningful API surface for the time being.
>>
>
> Then I will take the image filtering callback with all the costs it comes
> along with. Especially that with each passing year the relative cost of it
> will lessen, as the computer hardware improves.
>
>
> --
> Grzegorz Wr�bel
> 677265676F727940346E6575726F6E732E636F6D

 | 
Pages: 1
Prev: Find interactive user name / token (again) problems
Next: Time since wakeup?