| Comments

I’ve seen some reports and received some emails on email groups that I’m a part of around Windows 8 and Google Chrome browser and how touch is not working.  In fact I was initially confused about this myself because it was working fine for me on my machine (Lenovo x230t) but other people were insistent that it wasn’t working.  Then I asked what machine they were on.

Almost exclusively everyone was on a “high DPI” machine (or had high DPI settings in their display).  If you have a Surface Pro, for example, you are using a high DPI machine.  I installed Chrome on my Surface Pro and indeed saw the problem there.  After some digging it appears to be that Google Chrome is not yet a high DPI-aware desktop application (at least of this writing which was using version 30.0.1599.66 m – phew that was a mouthful of a version number).

Look at this screenshot.  This is from my Surface Pro with no changes.  I’m tapping on the 2nd image in the news highlights (indicated by the touch square indicator) but notice where the target is actually clicking – on the date “October 4” where the context menu is located:

Chrome missed touch target

I asked around the office and received one workaround, which I received, but also found a better one.  Here are both of them for you to consider.

Workaround 1: run in compatibility mode

This involves you getting to the properties of the chrome.exe program and viewing the compatibility tab.  In there you can check the option to disable DPI scaling:

Chrome compatibility setting

I didn’t like this option because immediately after restarting Chrome the display was crisp but “tiny” to see for my aging eyes.  You can see here is the msn.com site before/after this compatibility setting:

Chrome msn.com before

msn.com on Google Chrome with no compat setting

Chrome msn.com compat set

msn.com on Google Chrome with the compat setting enabled

After this setting the hit-targets are fine and work but the content is small (although admittedly more of it is viewable, but that is too small for me).  To mitigate this you can use Chrome’s zoom feature to zoom to 150% to match most closely the high DPI scaling that automatically happens.

Chrome zoom settings

But there has to be a better way…and is (in my opinion).

Workaround 2: set the Chrome flag for HighDPI Support

I learned that Chrome has “flags” that you can set to experiment with certain settings or override other default/automatic settings.  From the address bar, type “chrome://flags” and you’ll see a page of options.  Scroll near the end and you’ll see a “HighDPI Support Windows” setting which is set to Automatic. 

Chrome HighDPI Flag setting

Force this to Enable and re-launch Chrome.  Boom you are working again.  Simpler fix and gets you scaling on your device as well.  Now some of Chrome’s chrome (menus, etc.) aren’t as crisp still but the main content area doesn’t confuse hit-targeting of your touch interaction because of the scale.

The good part is that it appears that the Chrome team is aware of this and a Chrome bug is logged (Chromium Bug 271222: When using the global Windows UI scaling feature, touchscreen touches are off by the set scale).

I don’t use Chrome on a regular basis (nothing against it, just don’t need it) but do get sad when friends have problems so I like to try to help out.  Hopefully if you are in this case with your touchscreen and Google Chrome this will get you fixed up.

Hope this helps!

| Comments

Phoenix Silverlight User Group logoi was able to make it to the phoenix silverlight user group last night (2 separate trips downtown, yikes) and had a good time chatting with everyone there.  i understand that there will NOT be a separate march meeting because it essentially falls very close to when scott guthrie and others will be coming to town.  the group is recommending that people attend that to learn the latest and greatest about silverlight 2 right out of MIX!  we had a good discussion about various things.  mike palermo showed a couple of things he'd been working on including a simple game and a magnifier for photos (similar to the one michael has for video).  the concept was that you have a high resolution image on the page and then he had a magnification bubble that would react to the mouse wheel event on a mouse to zoom in/out of a selected area.  it looked in concept a lot of what like the Live Labs 'Seadragon' project describes as far as smooth zooming, etc.

one of the things mike did in this image magnifier is use a high-res image and basically clip it to the area being zoomed on for the mouse using transforms, etc.  i asked mike if he was using another image element or using an imagebrush.  i noted that i felt he should use an image brush rather than to use an existing image so that the image wasn't requested twice.  this is the efficient way of doing it when working with MediaElements and VideoBrushes so that the video in the brush is in sync as well as efficiently processed.  we worked up some pseudo code on the board real quick to describe what i was talking about.

well, i was slightly wrong.  the imagebrush element doesn't use 'sourcename' like a videobrush.  in videobrush you use the x:Name value of your mediaelement.  in the imagebrush you specify the actual image location (ImageSource).  i guess this somewhat surprised me so i started sniffing (thinking i made a mistake in my 'efficiency' statement.  when looking at the result of something like this:

<Image Width="240" Height="121" Source="silverlightUGwithText_6.jpg" 
         Stretch="Fill" x:Name="PhxUgLogo" 
         Canvas.Top="102" Canvas.Left="132"/>
  <Ellipse Width="107" Height="107"
           Stroke="#FFEC1818" Canvas.Left="224" Canvas.Top="250"
           StrokeThickness="5">
    <Ellipse.Fill>
      <ImageBrush ImageSource="silverlightUGwithText_6.jpg" 
                  Stretch="None">
        <ImageBrush.RelativeTransform>
          <TransformGroup>
            <ScaleTransform ScaleX="1.4" ScaleY="1.4"/>
          </TransformGroup>
        </ImageBrush.RelativeTransform>
      </ImageBrush>
    </Ellipse.Fill>
  </Ellipse>

there are actually 2 HTTP requests to the image source.  you can see them being requested.  what i've learned is that silverlight maintains an internal image cache anyway so the second request (although there and happening), would see the cached image instead.  so it looks like the method of using two Image elements would have the same effect...so given that i'm not sure either is 'better' than the other for doing this type of sample...what do you think?  regardless it was a cool demo.  thanks mike.

we talked a lot about why people are waiting for silverlight 2 and if that made sense.  we also had a good discussion of 'what if i just have casual media on my home page, why silverlight instead of flash' which is a question i hear a lot.  this discussion never revolves around technical issues (noted i said 'casual media' instead of high fidelity streaming, etc.) but rather around penetration of the plugin.  a lot of sites don't want to bear the load of plugin download/installation.  it's an interesting challenge when any new technology comes out and no different a discussion than when the .net framework first came out -- which 'app' was going to bear the installation tax in their app?  good discussion.