Venu dc.getwidth Reporting Incorrect Values?

I am getting some reports from some users of Venu that my datafield does not display correctly on their device. Everything works correctly on other devices and also on the emulator for the Venu. I calculate the screen size for the device by querying dc.getWidth(); and dc.getHeight(); Using the values returned to calculate the center and radius needed to draw on the screen.

As I say my code works perfectly on the emulator and no reports of this issue on other devices. On Venus it looks like it randomly reports the screen size as something bigger than 390x390 (the two images below show different displacement errors on the same device with the same version of data field). I have had this report from two independent Venu users now. Also included is a screenshot from the emulator. This error in the screen size changes, manifesting itself as my data field being pushed by a varying number of pixels to the right and up/enlarged on the users device.

Has anybody else seen this issue with the Venu and has any idea of the root cause of the issue?

Subset of code below:

    protected var absoluteCenterX = 0.0;
 	protected var absoluteCenterY = 0.0;
 	protected var widthX;
 	protected var heightY;

function onUpdate(dc) {
    var widthX = dc.getWidth();
    var heightY = dc.getHeight();
    absoluteCenterX = widthX / 2;
	absoluteCenterY = heightY  / 2;
    
 	var radius = (widthX - 5/2) / 2;
    dc.setPenWidth(5);
    c.setColor(Gfx.COLOR_LT_GRAY, Gfx.COLOR_BLACK);
    dc.drawArc(absoluteCenterX, absoluteCenterY, radius, 1, zone1Start, zone1End);
    }

0 jim_m_58 over 2 years ago

The width/height on a venu is 390, so the middle by doing width/2, height/2 is 195, but 195/195 isn't the absolute center (0 to 194 on the left, and 195 to 389 on the left. The actual center would be x=194.5, but x would be an int. You could even things out by drawing each arc 4 times, offsetting the x/y by 1 pixel each time, but that's 4x the draws. I'll do other things to only do a single draw (better for the battery)

When you do the setPenWidth, the radius will actually be the center of the arc, so based on what your center point is, part of the arc will be behind the bezel.

Consider doing something like this:

width=390

centerWidth=390/2=195

penWidth=5

radius=centerWidth-penWidth/2;

reduce the radius so the arc isn't as obscured by the bezel. Even in your sim screen shot, it looks to me that the blue arc is a different width than your red arc.. dc.getWidth() is correct and you just deed to adjust for things being ints. even if you did things like

absoluteCenterX=widthX/2.0 (so that would be a float and not an int), when used, it would be treated as an int as there are no factional x/y values for pixels.

I think the main issue is that you need to reduce the radius to accommodate for the pen width though.

0 Robert over 2 years ago in reply to jim_m_58

Thanks for the feedback but I am not sure I agree with your conclusions for the following reasons:-

1) When I had the problem previously reported from another Venu user I tried reducing the centre value to compensate for the 1 pixel error but this had no effect. I think the symptoms I am seeing are an increase in total canvas size by much more than 1 pixel over the actual canvas size

2) None of the symptoms are displayed in the emulator for the Venu (or any other device)

3) I cannot be sure but I would have thought I would have had more reports of this issue from other Venu users if it was a permanent feature of the Venu. I have 50k downloads for this data field variant and have had two reports of this issue.

4) I have had no reports of this issue from any user of any of my data fields (which are all based on the same base class of functionality for this drawing) for other devices.

5) radius is reduced by pen width/2

0 jim_m_58 over 2 years ago in reply to Robert

I have a number of apps that use arcs, and for sure, the radius is the center of the arc, so half of the pen width could be off screen with you use width/2 for that.

Things might be a bit more visible on devices with larger width (like the venu) than things that are 240x240. (5 pixels on a venu will look different than 5 pixels on a forerunner.)

Things with getWidth() work the same today as they did back when CIQ came out

0 Robert over 2 years ago in reply to jim_m_58

When decrease the radius by a full pen width I get the following in the emulator. This shows a very slight offset, caused by the half pixel error in the centre. But nothing like the offset being shown to me by two users on their devices.

In affect the decrease in radius by pen width/2 lets the outer ring bleed over the edge of the display, which masks the half pixel error in the center.

I am not suggestion there is a global problem with getWidth() but something odd seems to be happening with some Venu's

0 jim_m_58 over 2 years ago in reply to Robert

It could just be the screen isn't exactly centered in the bezel. Off by a hair...

0 Robert over 2 years ago in reply to jim_m_58

But the fault is only reported with my data field. Also if you look at the two pictures, from the user, the offset is different. Looking at the pictures from the user it looks to be more than could be supported by a mis alighted within the injection moulded housing. I must admit when I had the report from one Venu user about 12 months ago I put it down to some user/device issue. But when I got the same report from and second Venu user then I start think there must be another root cause.

0 jim_m_58 over 2 years ago in reply to Robert

There are lots of apps that use arcs (watch faces are common) and if this was a device issue, I would have expected others to report it, but I've not heard about it.

Maybe try to reproduce it in a really simple app, and include the whole souce in a bug report.

0 Robert over 2 years ago in reply to jim_m_58

I don't have a Venu, and I have never seen this issue on my device or the emulator. So I only have the reports of some end users to go on. If no one else has ever seen this problem then I will just have to chalk it down to one of those things? Cosmic Rays?

0 Robert over 2 years ago in reply to jim_m_58

Another weirdness of this report from the user is this artefact on one of their images from their screen. My software does not render anything like this. Seems like something else on the watch is get in on the act?