- Posts: 50
- Thank you received: 0
Microsoft Windows Phone 8.1 support ends (13 Jul 2017)
Microsoft has ended support for Windows Phone 8.1
Questions about Android development and PDF
Zoom-Problem on 64 bit
10 years 11 months ago #8861
by apait
Replied by apait on topic Zoom-Problem on 64 bit
i am on a macbookpro with Intel Core i5.
10 years 11 months ago - 10 years 11 months ago #8862
by support
Replied by support on topic Zoom-Problem on 64 bit
It's almost the same configuration I'll testing on.
I'll some check on real device to (Asus FonePad 2) as the multi touch support on the Emulator isn't so stable.
I think I'll be able to be back to you tomorrow late morning, early noon.
I'll some check on real device to (Asus FonePad 2) as the multi touch support on the Emulator isn't so stable.
I think I'll be able to be back to you tomorrow late morning, early noon.
Last edit: 10 years 11 months ago by support.
10 years 11 months ago - 10 years 11 months ago #8867
by Davide
Replied by Davide on topic Zoom-Problem on 64 bit
Hi,
sorry but today we wasn't able to finalize the tests.
We will close them tomorrow morning.
sorry but today we wasn't able to finalize the tests.
We will close them tomorrow morning.
Last edit: 10 years 11 months ago by support.
10 years 11 months ago - 10 years 11 months ago #8868
by support
Replied by support on topic Zoom-Problem on 64 bit
I could integrate what my colleague was writing: early test showed that a real atom 64bit device isn't showing the issue you are experiencing.
Tomorrow we will do a clean test removing arm and x86_32 architectures from apk structure.
Some Dev forum, also officially managed by google, says there could be an issue in multi touch emulation with 64bit architecture.
We will better update tomorrow.
Tomorrow we will do a clean test removing arm and x86_32 architectures from apk structure.
Some Dev forum, also officially managed by google, says there could be an issue in multi touch emulation with 64bit architecture.
We will better update tomorrow.
Last edit: 10 years 11 months ago by support.
10 years 11 months ago - 10 years 11 months ago #8872
by support
Replied by support on topic Zoom-Problem on 64 bit
We're back.
We wasn't able to check the library on a 64bit environment because it seems devices with 64bit CPUs like Zenfone 2 are running 32bit linux kernel.
We've found code.google.com/p/android/issues/detail?id=29735
Look at last post:
We was revisiting our code and actually we can say that:
- CPU optimized code is in the native library. From your video the rendering is running correctly.
- user interaction is on the java side. No code is tight to the CPU architecture... that's was the main reason Java and JavaVM was built. Now Dalvik and ART inherit the same philosophy.
I should ask you to better check your emulator environment, maybe enabling the showing of gestures and touch from the developers options.
We wasn't able to check the library on a 64bit environment because it seems devices with 64bit CPUs like Zenfone 2 are running 32bit linux kernel.
We've found code.google.com/p/android/issues/detail?id=29735
Look at last post:
Code:
The reason for the above problem seems to be that the emulator is misplacing the data it puts at the end of some of the messages it sends, shifting it by 4 octets. In turn, this is due to the alignment of the structures defined in the sdk-controller-socket.c source file.
The problem can be solved on 64-bit builds by either:
1) On line 279, add <<__attribute__((packed))>> (excluding the angle brackets) to the SDKCtlMessage struct, OR
2) On line 922, replace <<memcpy(msg + 1, data, size);>> with <<memcpy(&(msg->msg_type) + 1, data, size);>>
I prefer the second, because (a) it changes only the code where the copying is being made to the incorrect memory location, (b) it doesn't use gcc-specific extensions, and (c) it makes what the code is trying to do (copy the data to the memory after the msg_type member) explicit, whereas the original code looked as if it was trying to copy the data to the memory after the SDKCtlMessage struct (the two memory locations are identical if the struct alignment is 4 bytes instead of 8, of course).
We was revisiting our code and actually we can say that:
- CPU optimized code is in the native library. From your video the rendering is running correctly.
- user interaction is on the java side. No code is tight to the CPU architecture... that's was the main reason Java and JavaVM was built. Now Dalvik and ART inherit the same philosophy.
I should ask you to better check your emulator environment, maybe enabling the showing of gestures and touch from the developers options.
Last edit: 10 years 11 months ago by support.
10 years 10 months ago #8882
by apait
Replied by apait on topic Zoom-Problem on 64 bit
well, that can't be the issue.
the thread you posted is about multi-touch-emulation with a second device (using sdk-controller... that means you emulate sensor/touching on the emulator via a usb-connected android device), and the bug is, that the connection isn't establishing between the emulator and the device.
we've got users, telling us about that problem, so i started searching for days what it could be. i've got no x64-device to test with here, so i tested with the emulator and when i tried the x32_x64 processor i finally could reconstruct the reported behaviour.
as i said: exactly the same problem can be simulated with your test-app as well.
the thread you posted is about multi-touch-emulation with a second device (using sdk-controller... that means you emulate sensor/touching on the emulator via a usb-connected android device), and the bug is, that the connection isn't establishing between the emulator and the device.
we've got users, telling us about that problem, so i started searching for days what it could be. i've got no x64-device to test with here, so i tested with the emulator and when i tried the x32_x64 processor i finally could reconstruct the reported behaviour.
as i said: exactly the same problem can be simulated with your test-app as well.
Time to create page: 0.450 seconds