On , Ralf Schülke wrote:
Hello List, i will start this thread to found a good way to implementet the K4, ..K8 screen support aka "Retina Display".Basicly BeOS and Haiku works with pixel in a pixel matrix without add value "px"BRect (0, 0, 100, 300) and not BRect( 0px, 0px, 100px, 300px), so this make it good for a implementation he work automaticly to scale from pixel to dip. A simpel calculation are PIXEL / DEVICE_PIXEL_RATIO = DIP PIXEL = DIP * DEVICE_PIXEL_RATIO So we can implements two helper function as privat app_server code ig: float PixelToDpi(pixel) { // PIXEL / DEVICE_PIXEL_RATIO = DIP return new_pixel_dip; } float DpiToPixel(dip) { // PIXEL = DIP * DEVICE_PIXEL_RATIO return new_dip_pixel; } I found some information, i hope it help. the question is how smart can we implementet this without braking the API and for automaticly scaled. http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ https://www.brandbuilderwebsites.com/blog/2012/03/29/device-independent-pixel-formula-for-mobile-devices/ https://bbs.archlinux.org/viewtopic.php?id=39665 https://developer.appcelerator.com/question/125317/calculate-apps-density-pixel-width--height-using-titaniumplatformdisplaycapsdpi
yeah, that was a concern when I was looking at reving the Accelerant API for multiple displays and hardware 3D.
Monitor info should likely record the screen DPI from the driver to enable automatic detection of such things.
https://github.com/haiku/haiku/blob/master/headers/os/add-ons/graphics/Accelerant.h#L161I think maybe going "dpcm" is a better idea (metric) (http://en.wikipedia.org/wiki/Dots_per_centimetre)
As monitor_info is "experimental new Haiku API", I think it would be safe to add a uint32 dpcm item to the end?
I forgot this modification in my grand and far reaching accelerant API change that never happened :-)
-- Alex