Related
Claystone is a new 3D Android home screen replacement, media player, and launcher. We currently distributing developer preview betas to improve the product and get valuable feedback from the developer community. We are looking for feedback about the UI, stability, and overall functionality before we launch on Android Market.
What is unique about this home screen replacement is a 3D user interface with embedded viewers for video, photos, file browsing, web browser, YouTube, contacts, RSS news feeds, and more. The UI was designed for browsing content while you are viewing content.
Feature Summary
- Android 2.1 and higher home screen replacement
- Smart phone optimized
- 3D interface taking advantage of OpenGL
- Integrated media viewer apps for video, file browser, YouTube, web browser, photos, contacts, RSS reader, with more to come…
- Viewer apps bring functionality to the home screen and extending what you can do directly from your home screen in Android
- Claystone reduces the dependence on starting separate app for each media content type and our goal is to provide a more convenient and integrated experience
Widgets
- The Beta 3 widget experience will be replaced with a more standard widget implementation in Beta 4
Getting Started Tips
- Use the swipe left-right gesture to move through the stacked 3D panels
- The following items on the Home panel allow integrated viewing of content in the 3D interface: YouTube, Video, Photos, Contacts, File Browser, Web Browser, RSS Feeds
- Use the press-and-hold gesture throughout Claystone to access additional functions and options
Claystone is Now Available in Android Market
- Claystone is now available in Android Market
- Search for the keyword "Claystone"
Sounds sweet. I hope it won't force me to use popups for anything?
On my phone HTC HD2 (Android 2.3) will work?
Rosa Elefant said:
Sounds sweet. I hope it won't force me to use popups for anything?
Click to expand...
Click to collapse
Claystone launches Android Apps full screen and the panels load in a 3D stack that you can scroll through using a left-right finger swipe.
Great, worth a try then thanks!
vespend said:
On my phone HTC HD2 (Android 2.3) will work?
Click to expand...
Click to collapse
Android 2.1 and higher are supported so Android 2.3 should pose no issues.
We have tested on HTC devices and the screen resolution is also ideal for claystone.
Let us know if you have any issues.
Doesn't display well on HVGA screen...LG P500
> Doesn't display well on HVGA screen...LG P500
We've been working on getting a bunch more devices to test on. Stay tuned!
Hi. On my Original Droid when a screen is enlarged, it is off to my left and never 100% visible. Also, it was very slow. This may be due to my phone being rooted, but I had to uninstall.
cyanide911 said:
Doesn't display well on HVGA screen...LG P500
Click to expand...
Click to collapse
+1 I can confirm that. The dock icons are huge and the widgets misaligned.
Anyone tried this on a Droid X?
I'm gonna give it a try this evening. I think I tried the earlier beta a few days ago and it had issues as if the screen was off to the left etc. I attributed it to possibly a bad install or something.. I'll give beta 3 a go and report. Screenshot anomolies, etc.
Always a fan of new UI development.
Seems smoother, apps scoll much better-still not fluid yet. Widget screen is bigger. Will give overall in a little while. Limited widgets. Missing recent box-I liked that
On the right track though...
Love the concept of this launcher, but I cannot for the life of me figure out how to get portrait mode working. Using HD2 on 2.3.3 and it is always in landscape, and has no bottom bar.
Try it on the hd2 with cm7 and it work good I would make the 3d windows or what they are called a little bigger and maybe customizable options but other then that good work
Sent from my HTC HD2 using XDA Premium App
Added Widgets gone after a reboot to be never seen again. <-beta 2 retained these
Still sluggish
Would be nice to be able to resize/move panels
No picture/video bar across top on tablet
SD card (sd2) still not being seen only main storage
You tube still unstable, but better than beta 2
cannot see/launch launchbar
Keep up the good work-it's getting there
unfortunately, I still cannot use this as my daily launcher.
I think you will have more customers if you made a fully customizable one of these...
http://forum.xda-developers.com/showthread.php?p=13070948
http://forum.xda-developers.com/showthread.php?t=907551
On my phone, the window isn't centered, its too far right and down.
Also the dock is huge.
Nevertheless, this is a fresh idea and I see some potential.
Sent from my HTC Legend
It looks nice maybe i will try this on my sgs
Looks a bit like the palm os with the cards. Works fine at all, but it would be nice if the stacks were a little bigger. Maybe it would be possible that the cards go fullscreen when they get focus, and with the homebutton you can make them smaller to see them like its now in standard view.
But thats just a little idea.
Glad to see where this is going.
Sent from my HTC HD2 using XDA App
Beta 3
Still off to the left somewhat but better centered. Complicated to figure out. Videos are small and do not play in landscape and it's difficult to tell which windows are open esp difference between home, app..............Editing launcher bar is nice. Is there a settings (not the one for the phone or info for contact available via the app?
I just found this website with a fix for the keyboard lag in the stock browser:
smartadopter Wordpress -> TIP Improve Honeycomb Browser Speed
(I am new so not allowed to post outside links )
Basically it says:
1) as url type: about:debug
2) nothing will seem to happe.n BUT new menu options are available now
3) go to menu -> settings -> debug, and uncheck OpenGL Rendering
4) no more lag!
If this already floated around this forum, sorry. But if not, or for the people (like me) who missed it, enjoy!
I have not found any drawbacks of this fix. But if anybody find/knows any drawback/problem with this, please let me know.
Ill test this but im guessing scrolling speed will suffer as that uses the OpenGL.
Sent from my HTC Desire S using XDA App
Good advice. Will try it out now.
Tested and it works great. Scrolling is not affect either by this by the looks of it. Zooming works as well.
This fix isn't working. The input lag isn't gone completely, it's less noticeble, but it's still there.
And like someone mentioned before, scrolling isn's as smooth as before. Also YouTube videos don't work.
All this fix does is turn off hardware acceleration in the browser.
Some things get better, others get worse.
sassafras
Scrolling is not as smooth but I have no problems displaying YouTube movies.
But typing is a lot easier without (or with much less) lag.
So for me OpenGL rendering will stay off until the next update.
And lose my graphic acceleration? No thank you
No drawback?! Scolling looks like a freaking slideshow with that disabled ^^
Quick question for you guys... does the keyboard lag in Dolphin HD?
Not as much as the stock browser.
henkyie said:
I have not found any drawbacks of this fix.
Click to expand...
Click to collapse
For me the drawback is very obvious ... scrolling through a thread in this forum is horribly slow without OpenGL. But the keybord works like a charm.
I think, I will stay with Opera for forums and use the stock browser for the rest with OpenGL switched on ... loading times in Opera are much slower.
Thanks for the tip though.
I notice objects on the page rendering with every swipe as I move down the page ...probably why scrolling is not as smooth.
Strangely the scrolling lag has disappeared. So now I have less typing lag and little scrolling lag.
So until the next update I am a happy camper.
The only lag in typing I have left has to do with the auto complete function of the on screen keyboard.
This warrants further study (in the words of someone famous) because I'm seeing the exact opposite effect.
I've gone back and forth between this site and another forum having a similar javascript textarea form, comparing text entry with the "Enable OpenGL Rendering" box checked and unchecked in the Debug menu. On both sites, text entry is WAAAY faster using the dock keyboard with the box CHECKED. This is using the stock browser, BTW.
If I use a virtual keyboard (Swype for tablets in my case), it's still faster with OpenGL enabled but not nearly as fast as with the dock keyboard.
There must be some other factors involved however, since this behavior is not consistent. At times the keyboard (dock and virtual) seriously lags regardless of the Debug setting.
I sure hope Google (or ASUS) can fix this issue since it's hugely frustrating when the keyboard lags badly. In a few cases, I've just given up trying to post a message and pulled out my laptop instead of fighting the browser.
I needed a PDF viewer for my own purposes, and the closest I could find was Maciej's PDF Viewer (=apv) app on the market. It was open source, and so I made a bunch of changes that I wanted or needed. Anyway, I now have a pre-release for version 0.3.0, which include a bunch of enhancements since Maciej's 0.2.9 release.
Here it is.
New features:
- speed optimizations
- page number display
- options including: full screen, reverse video, various tweaks, page with volume keys
- overhauled file selection: added icons for directories, added home directory option
- better font rendering
Now I posted pre-release 0.3.0 pre 2. Includes a monochrome feature to save memory and a zoom-to-width feature which I think people will find handy.
Sounds like you know what your doing. Not had a chance to test your app yet, but does it have the functionality to add bookmarks and highlight text?
Gonna try it out now, thanks!
No, there is no annotation, sorry. Just reading.
Its really nice with open source alternatives. Im gonna try it out.
I think i will love this. thanks bud
I haven't tried it yet but it would be great if you could add zoom to a fixed percentage
the reason I want that is some pdfs have huge fonts for the page numbering and while technically fit to width is working, there's still a fair amount of room on the sides. Obviously this should be sticky. A bonus would be it would remember the setting by filename
Works good, one option I'd love to get is fixed scrolling like with browsers
sark666 said:
I haven't tried it yet but it would be great if you could add zoom to a fixed percentage
the reason I want that is some pdfs have huge fonts for the page numbering and while technically fit to width is working, there's still a fair amount of room on the sides. Obviously this should be sticky. A bonus would be it would remember the setting by filename
Click to expand...
Click to collapse
Zoom settings are indeed remembered by filename.
You can also adjust how much the zoom buttons zoom by. If you set that to 5% or 10%, you can do zoom-to-width and then press the zoom button once or twice.
Eventually, I'd like it to detect the real edges of the text.
moav said:
Works good, one option I'd love to get is fixed scrolling like with browsers
Click to expand...
Click to collapse
I couldn't figure out how to implement that. Moreover, I find it's poorly implemented in the browser--it locks much better on my device into horizontal movement than into vertical movement!
Instead, there is a "vertical scroll lock" option. This locks the scrolling to be only vertical, unless you make a serious (1/5 screen width) swipe left or right which temporarily unlocks horizontal scrolling.
I`ve just tested this app for half an hour with a bunch of PDFs littered in my Desire. This is without exaggeration the best pdf-viewer I´ve seen so far.
Very useful:
- zooming in steps as little as 5% because most PDFs were made for monitors or printing and not smartphones
- inverting the screen for reading at night or low-light conditions. It also saves power on my screen to read white text with black background.
- and it´s FAST
What I miss:
- an option to forget about the layout of a PDF, so I can only get the pure text. This would be very useful for PDFs designed for magazines with a columned layout, which is a pain to read on a handheld computer.
Keep up the good work
germanhoss said:
I`ve just tested this app for half an hour with a bunch of PDFs littered in my Desire. This is without exaggeration the best pdf-viewer I´ve seen so far.
Very useful:
- zooming in steps as little as 5% because most PDFs were made for monitors or printing and not smartphones
Click to expand...
Click to collapse
Remember, too, that if you set the 5% zoom option, you can still long-touch the zoom buttons for a 2X zoom.
arpruss said:
Remember, too, that if you set the 5% zoom option, you can still long-touch the zoom buttons for a 2X zoom.
Click to expand...
Click to collapse
Wow, haven´t noticed that - that´s quite useful.
Originally I thought of requesting a feature to remember the place where I closed the document because I´m used to open things in the ES explorer.
Then I stumbled through the built-in file explorer - feature implemented
Maybe an FAQ or a short manual would be useful ...
germanhoss said:
Wow, haven´t noticed that - that´s quite useful.
Originally I thought of requesting a feature to remember the place where I closed the document because I´m used to open things in the ES explorer.
Then I stumbled through the built-in file explorer - feature implemented
Maybe an FAQ or a short manual would be useful ...
Click to expand...
Click to collapse
There is a wiki on the project page. You can add a FAQ.
It's a great light app and it has some cool features which I miss on other apps. But my primary feature for PDF readers is smoothness.
It would be great if it would be working as smooth as Documents To Go (their PDF reader). By smooth I mean smooth rendering and scrolling. Also it won't hurt to have multitouch zooming.
I know it's easy to demand and hard to do but at least there are ideas what should be present in the next versions.
jankoboys6 said:
It's a great light app and it has some cool features which I miss on other apps. But my primary feature for PDF readers is smoothness.
It would be great if it would be working as smooth as Documents To Go (their PDF reader). By smooth I mean smooth rendering and scrolling.
Click to expand...
Click to collapse
That's largely a matter of speed, and it's going to be hard to improve that, except by expending a lot of memory for caching and background rendering.
Also it won't hurt to have multitouch zooming.
Click to expand...
Click to collapse
I agree, but it is a finicky feature to implement correctly and hence requires a multitouch device for debugging. I don't own one. Moreover, there are potential patent issues.
I've just posted 0.3.0 pre 13. This unfortunately has a new bookmark database, not compatible with previous versions, so people will lose their per-document settings. I am hoping this is the last such loss--the new format will make code maintenance easier and is easily upward expandable.
New features/fixes in pre 13:
- store horizontal offset in per-document settings
- better restore of zoom if orientation has changed
- fix round-off error which resulted in occasional horizontal one-pixel-width errors
I would also like to mention the color feature in your app is really great! Now I can read without hurting my eyes in the dark and it saves batter as well. Great feature indeed!
arpruss said:
That's largely a matter of speed, and it's going to be hard to improve that, except by expending a lot of memory for caching and background rendering.
Click to expand...
Click to collapse
hmmm what if you make the memory size for caching an option in the settings for users to choose their optimum size? Do you believe that this would make any speed improvements?
arpruss said:
I agree, but it is a finicky feature to implement correctly and hence requires a multitouch device for debugging. I don't own one. Moreover, there are potential patent issues.
Click to expand...
Click to collapse
I see it's kind a hard/expensive to make this feature possible. Darn US laws on patents :-/ don't know if in EU is the same for Android apps but for C++ and other programming languages, there are no e-patents.
Keep on your great work!
PS: I'm using HTC Desire (CM7 rom)
jankoboys6 said:
I would also like to mention the color feature in your app is really great! Now I can read without hurting my eyes in the dark and it saves batter as well. Great feature indeed!
hmmm what if you make the memory size for caching an option in the settings for users to choose their optimum size? Do you believe that this would make any speed improvements?
Click to expand...
Click to collapse
Maybe, but it would need a smarter pre-render queue than we currently have. I experimented with making one, but my attempts were buggy so I got rid of them.
Tell me which scrolling pattern you'd like to be faster? Currently the app (in render ahead mode) is optimized for ebook reading: you read a page, and while you read the page, the next one is rendered and shows up instantly when you flip pages (I generally do that with the volume-down key) or scroll vertically to it.
Unfortunately, there seems to be a bug somewhere, perhaps only on devices with larger screen resolutions (it works fine on my 854x480 Archos, but I am told that it doesn't work on a 1280x960 screen), which makes the next page not show up instantly.
What would you like to be improved on your stock Sensation
Htc Sensation improvements & bugfixes
Improvements:
Android 2.3.4 or 2.3.5 (mainly for gtalk video)
Improved speed.
Improved stability.
Battery life improvements.
Ability to remove certain apps like htc locations, peep, friends stream, stocks, reader, dices & teeter.
Bugfixes:
WiFi deathgrip.
Screen unresponseness.
Mail app keeps storing the same attachments a 100 times!?
Please add things you would like to see in the next update (i hope someone from Htc will read this)
I just got my Sensation 3 days ago. Here's what I'm wanting so far:
- these 7 spinning Home pages - I cant seem to get a few to go away
- the phone pad covers up the speakerphone and end call/call buttons
- stop the BRIGHT light on start-up....make it black or something
- delete apps, or organize apps
- obviously the speaker sucks, so anything to improve that
- be able to adjust the auto-brightness - down some at least
- my turn-off automation doesnt seem to stop all the automation
*keep in mind i'm a noob, prob some simple answers to these I just dont know yet
I'd like it to feel like it actually has two cores running at a higher clockspeed than the Desire HD, instead of feeling slower.
Being able to remove inbuilt applications in the applications console would be great.
Apart from that, tis nice
I would just like to see them refine Sense 3.0, the home screen lag and constant reloading are too annoying. If they refined the launcher to use less RAM and fixed some of the bugs, I'd be happy.
you and me both...
gerryjoson said:
I'd like it to feel like it actually has two cores running at a higher clockspeed than the Desire HD, instead of feeling slower.
Being able to remove inbuilt applications in the applications console would be great.
Apart from that, tis nice
Click to expand...
Click to collapse
this is the only phone, out of the EVO 3d, Samsung g2 and the LG G2x where the validity, or visible evidence of dual core speed is perpetually questioned. Whether Sense is not "optimized" or one core is working until certain processes need it, the phone does not, IMO, hang with its competition in its stock form.
ps- did I mention that I would like the FIRST FREAKING UPDATE here in the UU on T-Mo. Everyone else around the globe wants "another" one and we have yet to get our first (to my knowledge).
Speaker improvement, try and alleviate the WiFi issues, better BT support, and just overall optimization.
What I would like is to get the contact I am pressing instead of someone else in the text messaging.......... I have no idea how this is still an issue Oh and perhaps sense not restarting every time I exit a program, getting a little tired of the white HTC screen!
Saw this one on google+ and I think it's a nice read and very informative
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
All credit goes to Dianne Hackborn. Thanks for sharing this!
HAHAHAHA good facts, and very interesting!
Great post
yup, Nice Post!
Interesting observation!