Prima rom e poi kernel
Inviato dal mio Full Android on Bravo usando Androidiani App
Visualizzazione stampabile
Prima rom e poi kernel
Inviato dal mio Full Android on Bravo usando Androidiani App
come ti sembra, cambiata molto rispetto a ginger
la tastiera è migliorata?
grazie
A mio aviso non sono nemmeno parenti... la tastiera ē identica cambia solo l effatto di quando schiacci i tasti.... cmq molto bella
Inviato dal mio Full Android on Bravo usando Androidiani App
comunque c'è ancora la camera che non va e l'accelerazione hw non è completa, oltre a qualche bug sparso qua e la :)
Io aspetto ancora qualche sviluppo prima di metterla su :)
A livello prestazioni ora come siamo rispetto a ginger?
Il browser come va?
Comunque leggendo su xda lo sviluppatore si sta un po' scocciando :|
Non si puo fare ancora un raffronto... cmq pensando che è ancora una alpha gira gia molto bene.... cosa intendi che si sta scocciando???
Inviato dal mio Full Android on Bravo usando Androidiani App
questo:
***unsupported*** - so you need to fix it yourself and not ask for help here or the development of this ROM will end...Quote:
Wow a fast rom. I love this build. Thx for the developers.
But I cant sync with facebook. Any ideas?
Sent from my Full Android on Bravo using XDA App
Noooooooo se non puo terminare lo sviluppooooo
Inviato dal mio Full Android on Bravo usando Androidiani App
video di ICS con hack accelerazione hw:
http://www.youtube.com/watch?v=wnf5jbxGLbA
La sto ptovando da ieri sera e devo dire k è veramente fluida...vi sto scrivendo proprio da li...comunque volevo sapere se era possibile installare uno script per la memoria..tipo data2ext????
Anche a me interesserebbe... sinceramente pensavo che diventasse com il nexsus prime che mette tutto.nella stessa memoria
Inviato dal mio Full Android on Bravo usando Androidiani App
beh la cosa è diversa, il nexus non partiziona la sua memoria interna in system/data/cache e mette tutto insieme.
Il nostro problema è un altro... noi abbiamo 2 memorie fisiche, una rom interna (che è partizionata) ed una SD esterna (semplici dati utente).
Quindi tutt'alpiù su ICS non ci sarà bisogno di un partizionamento della ROM (ma ne dubito), ma non penso che si riesca a fare in modo che ROM+"una partizione dell'SD" siano viste come unica memoria senza per l'appunto uno script come l'A2SD+ (che implementeranno successivamente nella rom).
In effetti hai ragione....
Inviato dal mio Full Android on Bravo usando Androidiani App
Io ho provato a flashare uno script ma la memoria non è cambuata..i soliti 150
.a cm si fa a dare cosi poca memoria a un cellulare del genere...
Un tempo era cosi ora infatti mettono dal gb in su
Inviato dal mio Full Android on Bravo usando Androidiani App
Non lo sapevo .... ora ci guardo
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Ciao a tutti, sto provando ora la rom tramite boot manager, e mi sembra molto piu fluida rispetto a prima,anche se non ho ben capito come funziona questo hack e perche non piace allo sviluppatore. Personalmente ho visto che il navigon non funziona, il vostro navigatore funziona?
Io uso quello di google e funge...
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Avete notato ke se usate la trackball appare la freccietta sullo schermo? =D
Si odiosa... io lo utilizzavo tantissimo il track.... ed ora mi ritrovo sta cacca di mouse...haha
ha ma scusate anche a voi quando scrivete del testo vi sottolinea tutto quello che scrivete ??? A me non va neanche il dizzionario uff
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Si si, sottolinea tutte le parole anke a me.....anke avendo inpostato la tastiera italiana xD
A ok allora non sono l unico
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Si si sottolinea tutto anke a me.........anke avendo impostato la tastiera italiana xD
L'hack per l'accelerazione hw non so di preciso in cosa consista ma penso che sia una cosa del genere:
Quando il sistema richiede la visualizzazione di un componente richiama una funzione grafica, mettiamo disegna() a cui passa degli argomenti che indicano cosa vuole che sia elaborato e quindi visualizzato a schermo.
Quindi mettiamo che dica disegna("la barra di notifica, vuota, nera");
I driver grafici ricevono la chiamata ed elaborano la cosa, restituendo "A1 B5 26 38 00 FF 45 B3", che inviato allo schermo ci consente di visualizzare i 96 pixel neri della barra di notifica. Questa elaborazione può essere eseguita o da driver ICS (che faranno tutto più velocemente) o da driver senza accelerazione hw, che faranno tutto più lentamente.
Io penso che l'hack sfrutti il fatto che alcuni elementi della UI rimangono sempre invariati e pertanto le richieste sono sempre quelle.
Quindi lo sviluppatore ha visto cosa un driver "sano" restituisce e l'ha copiato.
Quindi, quando la nostra rom richiederà la visualizzazione della barra di notifica:
disegna("la barra di notifica, vuota, nera");
Il OS non passerà la chiamata ai driver, ma darà direttamente il risultato "A1 B5 26 38 00 FF 45 B3", senza quindi bisogno di elaborazione.
Ovviamente questo è un sistema che funziona solo in alcuni casi e con elementi predefiniti e non può essere considerata vera e propria accelerazione hw.
Comunque ripeto, queste sono solo mie congetture, se qualcuno ne sa di più mi illumini.
s8vuoto, volevo chiederti qualcosa su boot manager...
Se lo installo, posso tenere la rom che ho ora, senza perdere nessun dato, ed installarne una nuova su uno "slot vuoto" ?
Visto che va a modificare la procedura di avvio della recovery e visto che questa è la nostra ancora di salvezza, c'è rischio di brick o simili ?
Ho sentito che in recovery si entra collegando il caricabatterie a telefono spento...è vero ? E quindi se devo caricare semplicemente il cellulare da spento come faccio ? :D
Grazie :)
Io Boot Manager nn sono mai riuscito ad usarlo perchè nn mi faceva installarre Rom negli spazi vuoti.
Per la recovery devi spegnere il telefono poi riacciìdendilo tenendo premuto il tasto di accensione e il volume -.....se nn ti entra prova a togliere la batteria e riprova....
ah....in questo caso nn saprei....
Anche a me sarebbe piaciuto installare ics usando boot menager ma nom riesco a capire come funziona... qulcuno lo sa??
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Qualche novità per quanto riguarda la memora???
Per ora nulla
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Ieri è stato postato un commento che chiarisce bene il concetto di accelerazione hw, vi consiglio di leggerlo:
Quote:
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...-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.
E' stato aperto un nuovo thread su xda inerente alla rom con l'hack per l'accelerazione hw, così da non intasare il thread dev:
Inoltre, un altro video sulla rom con l'hack per l'accelerazione hw:Quote:
This is a thread for all of those interested in the HW Hack that has been applied to the current WIP ICS for Desire ROM. This is to keep you out of the development thread for the ICS ROM and keep it clean. Any questions should be asked in here and if anyone wants to develop it, go ahead. As mentioned many times in the original thread, they are not supporting this, so don't ask them! Funnily enough, neither am I, I am sick of reading questions pertaining to something that is mentioned every page as UNSUPPORTED.
http://www.youtube.com/watch?v=yZ6g-29pgwo
ok per l'accellerazione Hardware ci siamo..ma la MEmoria la vogliamo sistemare??? ce è impossibile usare un cellulare con quei pochi megabyte a disposizione..ce assurdo ho installato solo whatsapp e mi da problemi di memoria..eddaii :O
forse non avete capito che questa rom non è per il daily use, non è una versione stable ne tanto meno una beta, è un alpha.
L'A2SD+ sarà probabilmente una delle ultime cose che implementeranno, perché a nessuno interessa introdurre una funzione per avere spazio per le app su una rom test, funzione inoltre che può introdurre diversi problemi (ed aggiungere problemi o problemi non è certo il modo di risolverli).
Comunque a fluidità sembra veramente ottimo!
cmq io è quasi 2gg che la uso e non ho avuto neanche un impuntamento
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App
Sono 2 giorni che la uso , a parte il problema della memoria nessun impuntamento, browser molto veloce ricezione e batteria ottimi.
Ragazzi leggendo tutto il thread ho notato che la ROM è molto funzionale pur essendo un Alpha e volevo chiedervi prima di mettere le mani sul mio desire come installarla, se potevate darmi delle delucidazioni sull'installazione grazie
Si instilla come tutte le altre rom
Inviato dal mio HTC DESIRE ICS 4.0.1 usando Androidiani App