Firefox, 64-bit anche per Windows

Il browser del Panda Rosso torna ad offrirsi agli sviluppatori in una versione per Windows a 64-bit: la concorrenza si è già adeguata ed è l'evolvere del Web che lo richiede

Roma – La giovane Developer Edition di Firefox si è dotata di una build 64-bit dedicata ai sistemi Windows: era stata annunciata contestualmente ai festeggiamenti per il decennale del browser ed ora è disponibile nel canale dedicato agli sviluppatori.

Lo sviluppo di build a 64 bit per sistemi Windows era stato interrotto nel 2012: gli sviluppatori di Firefox avevano scelto di concentrarsi sulle build a 32-bit per problemi di instabilità e bug troppo complessi da risolvere con le risorse a disposizione della community. Ora sembra giunto il momento di riallinearsi alla concorrenza di Chrome e di Internet Explorer.

Con l’evolvere di applicazioni web sempre più complesse, ad esempio con l’avanzare delle frontiere della videoludica incastonata nel browser, le esigenze sono cambiate: lo spazio di indirizzamento va aumentato oltre i 4 GB concessi dai 32-bit e un browser a 64-bit può fare la differenza, ripercuotendosi anche sulle prestazioni in termini di velocità. Mozilla cita l’esempio del subset JavaScript asm.js (che anche Microsoft ha scelto di supportare per Windows 10): con l’aumento dello spazio di indirizzamento dato dalla versione 64-bit e la possibilità di sfruttare nuovi registri e istruzioni hardware, gli incrementi prestazionali vanno dall’8 al 17 per cento, garantendo al contempo una maggiore sicurezza, con la possibilità di appieno le misure di protezione ASLR.

Mozilla suggerisce agli sviluppatori che vogliano mettere alla prova la build 64-bit di Firefox 38.0a2 di disinstallare la versione Win32 senza rimuovere il proprio profilo prima di scaricare la versione desiderata.

Gaia Bottà

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Fra scrive:
    OpenGl vs Vulkan
    Le OpenGl hanno il problema che non girano su ARM ... Vulkan invece si, per questo non sn compatibili con OpenGl.
    • collione scrive:
      Re: OpenGl vs Vulkan
      non è certamente il motivo più importantela vera ragione sta nell'architettura completamente differente della nuova apima il nocciolo della questione è che quest'api ti dà:1. performance migliori2. meno bug3. driver più semplici4. maggior controllo in mano alle applicazioni
      • Qualcuno scrive:
        Re: OpenGl vs Vulkan
        - Scritto da: collione
        1. performance migliori
        2. meno bug
        3. driver più semplici
        4. maggior controllo in mano alle applicazioni5. maggiori difficoltà per gli sviluppatori che devono usarle.Non dimentichiamo che le OpenGL, pur con i loro limiti dovuti a 25 anni di storia e retrocompatibilità, offrono delle API di livello più alto. Con Vulkan solo le grandi software house (e, speriamo, grandi progetti open source) saranno in grado di creare motori grafici, gli altri dovranno limitarsi ad appoggiarsi a questi progetti.
        • collione scrive:
          Re: OpenGl vs Vulkan
          Ma l'idea è che chi non ha i mezzi non dovrebbe mettersi a pasticciare con i motori grafici
          • Qualcuno scrive:
            Re: OpenGl vs Vulkan

            Ma l'idea è che chi non ha i mezzi non dovrebbe
            mettersi a pasticciare con i motori
            graficiIo penso a progetti tipo Blender, per dirne uno. Usano ancora le OpenGL 1.x, perché sono tutt'ora la più facili da usare per questo tipo di software! Credo che l'intero mondo dei modellatori 3D e CAD sia in una stuazione simile.
          • pippo scrive:
            Re: OpenGl vs Vulkan
            - Scritto da: collione
            Ma l'idea è che chi non ha i mezzi non dovrebbe
            mettersi a pasticciare con i motori
            graficila tua idea forse, il resto del mondo non nasce studiato e impara dai propri errori, pasticciando e sperimentando.
    • Shu scrive:
      Re: OpenGl vs Vulkan
      - Scritto da: Fra
      Le OpenGl hanno il problema che non girano su ARM
      ... Vulkan invece si, per questo non sn
      compatibili con
      OpenGl.Le OpenGL "complete" non girano su AMR, ma OpenGLSL sì.Vulkan è stato progettato con il mobile in mente, quindi è pensato per girare anche con poche risorse.
    • giucam scrive:
      Re: OpenGl vs Vulkan
      - Scritto da: Fra
      Le OpenGl hanno il problema che non girano su ARM
      ... Vulkan invece si, per questo non sn
      compatibili con
      OpenGl.Non c'è nessuna incompatibilità fra OpenGL e ARM. In genere su telefoni e aggeggi del genere non ci sono le OpenGL complete ma le OpenGL ES, con alcune cose in meno, ma non ha nulla a che vedere con l'architettura della CPU/GPU.
      • Luppolo scrive:
        Re: OpenGl vs Vulkan

        Non c'è nessuna incompatibilità fra OpenGL e ARM.
        In genere su telefoni e aggeggi del genere non ci
        sono le OpenGL complete ma le OpenGL ES, con
        alcune cose in meno, ma non ha nulla a che vedere
        con l'architettura della
        CPU/GPU.Esattamente. In realtà le GLES che sono state definite anche loro da Khronos, richiedono al programmatore di scriversi gli shaders a mano, cosa che le GL non fanno, in quanto gli shaders sono già compilati.Peccato che per ogni luce che piazzi devono calcolare l'effetto su ogni singolo pixel della scena e se usi l'alpha channel la complessità diventa ancora maggiore.Consentendo al programmatore di scrivere gli shaders, gli consenti di scegliere il giusto compromesso tra velocità e complessità, che serve a lui, cablandosi applicazioni su misura e per questo sono lo standard delle WebGL.Quello che però sembra veramente rivoluzionario, è la definizione dell'OpenCL. Considerato che il processore di un modulo grafico di uno smartphone è in grado di eseguire centinaia di calcoli vettoriali paralleli in virgola mobile in un microsecondo, poter riusare questi dati a livello di CPU invece che per la semplice rappresentazione grafica, è una possibilità completamente nuova nello sviluppo di giochi e algoritmi vari.
        • giucam scrive:
          Re: OpenGl vs Vulkan
          - Scritto da: Luppolo

          Non c'è nessuna incompatibilità fra OpenGL e
          ARM.

          In genere su telefoni e aggeggi del genere non
          ci

          sono le OpenGL complete ma le OpenGL ES, con

          alcune cose in meno, ma non ha nulla a che
          vedere

          con l'architettura della

          CPU/GPU.

          Esattamente. In realtà le GLES che sono state
          definite anche loro da Khronos, richiedono al
          programmatore di scriversi gli shaders a mano,
          cosa che le GL non fanno, in quanto gli shaders
          sono già
          compilati.Eh? No, questa differenza non esiste. Devi scriverti gli shader, se li vuoi usare, qualunque sia la versione di OpenGL.
          Quello che però sembra veramente rivoluzionario,
          è la definizione dell'OpenCL.


          Considerato che il processore di un modulo
          grafico di uno smartphone è in grado di eseguire
          centinaia di calcoli vettoriali paralleli in
          virgola mobile in un microsecondo, poter riusare
          questi dati a livello di CPU invece che per la
          semplice rappresentazione grafica, è una
          possibilità completamente nuova nello sviluppo di
          giochi e algoritmi
          vari.Questa non è una novità, è da anni che si fa.
          • Luppolo scrive:
            Re: OpenGl vs Vulkan
            Forse non hai capito che il punto portato avanti da Khronos non è ampliare ciò che già esiste, ma ridurlo per renderlo adatto ai dispositivi poco potenti.Ovviamente le GL supportano gli shaders, però puoi anche non usarli e se non li usi, fanno tutto loro con il Gourad shading e l'alpha, dando per scontato la potenza di calcolo.Le GLES ti obbligano ad usare gli shaders e quindi sei obbligato a vedere le cose da un punto di vista diverso.Per quanto riguarda OpenCL invece, il linguaggio è standard ma non è implementato su gran parte dei sistemi.Per esempio non c'è nello standard di programmazione Android, la cui piattaforma base è Java su ARM e quindi, avrebbe sicuramente bisogno di un incremento di prestazioni anche su altri fronti, oltre alla rappresentazione grafica.
          • giucam scrive:
            Re: OpenGl vs Vulkan
            - Scritto da: Luppolo
            Forse non hai capito che il punto portato avanti
            da Khronos non è ampliare ciò che già esiste, ma
            ridurlo per renderlo adatto ai dispositivi poco
            potenti.Si, quello mi è chiaro. Stavo solo cercando di farti notare delle tue imprecisioni.

            Ovviamente le GL supportano gli shaders, però
            puoi anche non usarli e se non li usi, fanno
            tutto loro con il Gourad shading e l'alpha, dando
            per scontato la potenza di
            calcolo.Detta così suona diversamente da quello che hai detto prima. Comunque, stai parlando di OpenGL fixed function, glBegin()/glEnd() e compagnia. Quello è OpenGL 1, e anche se sono presenti ancora fino all'ultima versione di OpenGL è decisamente una cattiva abitudine usarli. Se non hai bisogno di prestazioni però, puoi.Da notare però che da 3.1 in poi c'è la distinzione fra Core e Compatibility context in OpenGL. Il Core context elimina la fixed function pipeline, quindi sei costretto a usare gli shader. Mesa e, mi pare, Apple, non supportano Compatibility context oltre il 3.1, ma solo Core.

            Le GLES ti obbligano ad usare gli shaders e
            quindi sei obbligato a vedere le cose da un punto
            di vista
            diverso.

            Per quanto riguarda OpenCL invece, il linguaggio
            è standard ma non è implementato su gran parte
            dei
            sistemi.

            Per esempio non c'è nello standard di
            programmazione Android, la cui piattaforma base è
            Java su ARM e quindi, avrebbe sicuramente bisogno
            di un incremento di prestazioni anche su altri
            fronti, oltre alla rappresentazione
            grafica.A quanto mi risulta, su Android OpenCL c'è, ma per questioni politiche non puoi usarlo nelle app ma solo una libreria a più alto livello che internamente usa OpenCL.
          • Luppolo scrive:
            Re: OpenGl vs Vulkan

            Detta così suona diversamente da quello che hai
            detto prima. Si, è che a volte è difficile discutere di certi argomenti senza essere prolissi e da queste parti c'è pure gente con l'insulto facile purtroppo.
            Comunque, stai parlando di OpenGL
            fixed function, glBegin()/glEnd() e compagnia.
            Quello è OpenGL 1, e anche se sono presenti
            ancora fino all'ultima versione di OpenGL è
            decisamente una cattiva abitudine usarli. Se non
            hai bisogno di prestazioni però,
            puoi.
            Da notare però che da 3.1 in poi c'è la
            distinzione fra Core e Compatibility context in
            OpenGL. Il Core context elimina la fixed function
            pipeline, quindi sei costretto a usare gli
            shader. Mesa e, mi pare, Apple, non supportano
            Compatibility context oltre il 3.1, ma solo
            Core.Si, la mia esperienza sulla storia di OpenGL non è così approfondita. Le ho usate su Linux tempo fa, poi recentemente ci ho sviluppato per gioco su Android che ovviamente supporta solo le GLES.Ho scritto un paio di shaders col Bling-Phong e un piccolo motore grafico, usando ottimizzazioni per ottenere la trasparenza senza alpha, così quando sono tornato a dare una occhiata a OpenGL classiche mi sono accordo del lavoro immane che fa in più la scheda grafica (anche se penso che molto dipenda dall'implemntazione).Ho visto che glBegin() e glEnd() sono deprecate ormai, ma anche le glVertex / normal ecc... pointer che non sono deprecate e che si usano con gli shaders, possono essere usati anche senza, o per lo meno io l'ho fatto, quindi presumo che gli shader siano già precompilati o quantomeno gestiti dalle librerie in modo globale.




            Le GLES ti obbligano ad usare gli shaders e

            quindi sei obbligato a vedere le cose da un
            punto

            di vista

            diverso.



            Per quanto riguarda OpenCL invece, il linguaggio

            è standard ma non è implementato su gran parte

            dei

            sistemi.



            Per esempio non c'è nello standard di

            programmazione Android, la cui piattaforma base
            è

            Java su ARM e quindi, avrebbe sicuramente
            bisogno

            di un incremento di prestazioni anche su altri

            fronti, oltre alla rappresentazione

            grafica.

            A quanto mi risulta, su Android OpenCL c'è, ma
            per questioni politiche non puoi usarlo nelle app
            ma solo una libreria a più alto livello che
            internamente usa
            OpenCL.Non lo so, io lo stavo cercando per fare il motore logico di un giochino ma non l'ho trovato. Ho trovato discussioni come queste :http://stackoverflow.com/questions/9005352/how-to-use-opencl-on-androide ho lasciato perdere, ma magari oggi sono cambiate un po` di cose e sicuramente, se ci fosse uno standard insieme a GLES sarebbe meglio.
          • giucam scrive:
            Re: OpenGl vs Vulkan
            - Scritto da: Luppolo
            Ho visto che glBegin() e glEnd() sono deprecate
            ormai, ma anche le glVertex / normal ecc...
            pointer che non sono deprecate e che si usano con
            gli shaders, possono essere usati anche senza, o
            per lo meno io l'ho fatto, quindi presumo che gli
            shader siano già precompilati o quantomeno
            gestiti dalle librerie in modo
            globale.Ti confondi. glVertex/Color/Normal/... si usano con glBegin/End, e sono deprecate. Con gli shader usi o vertex buffer object oppure al limite glVertexAttribPointer passandogli un puntatore a un array di vertici in RAM.
            Non lo so, io lo stavo cercando per fare il
            motore logico di un giochino ma non l'ho trovato.
            Ho trovato discussioni come queste
            :

            http://stackoverflow.com/questions/9005352/how-to-

            e ho lasciato perdere, ma magari oggi sono
            cambiate un po` di cose e sicuramente, se ci
            fosse uno standard insieme a GLES sarebbe
            meglio.Io di Android non me ne intendo, ma lo standard c'è: OpenCL. Se poi i telefoni in giro non lo supportano è un'altro discorso, e non credo che OpenCL 2.1 cambierà qualcosa.
          • Luppolo scrive:
            Re: OpenGl vs Vulkan

            Ti confondi. glVertex/Color/Normal/... si usano
            con glBegin/End, e sono deprecate. Con gli shader
            usi o vertex buffer object oppure al limite
            glVertexAttribPointer passandogli un puntatore a
            un array di vertici in
            RAM.
            Hai ragione ... ho rivisto adesso, nella versione GLES di android si usa :GLES20.glVertexAttribPointermentre in effetti con il C++ e le openGL ho usato :glVertexPointerChe è deprecata.Siccome le chiamate sono simili, cioè alla fine gli passi un array di elementi dandogli il tipo e la geometria.Pensavo fossero la stessa cosa, come ti ho detto non era un programma professionale, ma una roba fatta per diletto.Bene quindi ho capito ... ma alla fine cosa è rimasto delle OpenGL che conoscevo tanti anni fa ? Ben poco visto che nelle 3.1 come hai detto tu hanno rimosso il tutto dal core.
          • pippo scrive:
            Re: OpenGl vs Vulkan
            - Scritto da: Luppolo
            Si, la mia esperienza sulla storia di OpenGL non
            è così approfondita. Le ho usate su Linux tempo
            fa, poi recentemente ci ho sviluppato per gioco
            su Android che ovviamente supporta solo le
            GLES.volevo correggere un tuo precedente post ma ora che ho letto che non hai esperienza su OpenGL non infierisco. Posso solo dire che si vede.
          • Luppolo scrive:
            Re: OpenGl vs Vulkan
            - Scritto da: pippo
            - Scritto da: Luppolo

            Si, la mia esperienza sulla storia di OpenGL non

            è così approfondita. Le ho usate su Linux tempo

            fa, poi recentemente ci ho sviluppato per gioco

            su Android che ovviamente supporta solo le

            GLES.

            volevo correggere un tuo precedente post ma ora
            che ho letto che non hai esperienza su OpenGL non
            infierisco. Posso solo dire che si
            vede.Non c'è nulla da infierire, si sta discutendo tranquillamente, le OpenGL le ho usate poche volte nella vita e quasi sempre per studio.Mi fa piacere discutere con gente esperta ed ammettere i miei errori,.Avevo postato all'inizio dicendo che giucam aveva ragione e che la compatibilità con ARM non c'entrava (che è vero) solo che non ero così esperto da capire le sfumature che giustamente mi avete fatto notare.Ora ne so di più di prima e questo non è mai un peccato. ;)
  • dumah scrive:
    ennesimo fallimento del mondo open
    le OpenGL hanno fallito =
    ennesimo fallimento del mondo open.Ci fosse un progetto open che venga adottato seriamente!
    • Giulia scrive:
      Re: ennesimo fallimento del mondo open
      Apache2 quindi lo mettiamo nel cesso direttamente?
      • Capperi scrive:
        Re: ennesimo fallimento del mondo open
        Lo standard TCP-IP al bando!E' open pure lui!Lascialo stare, non sa ma parla.
      • pippo scrive:
        Re: ennesimo fallimento del mondo open
        - Scritto da: Giulia
        Apache2 quindi lo mettiamo nel cesso direttamente?ma anche si, meglio nginx
    • Shu scrive:
      Re: ennesimo fallimento del mondo open
      - Scritto da: dumah
      le OpenGL hanno fallito =
      ennesimo fallimento
      del mondo
      open.
      Ci fosse un progetto open che venga adottato
      seriamente!Le OpenGL vengono usate su tutti i giochi mobile, per Android e per iOS, oltre che per diversi giochi per Windows e praticamente tutti quelli per Linux e OSX.Se chiami fallimento questo, voglio fallire anche io!
    • Jaguaro scrive:
      Re: ennesimo fallimento del mondo open
      Ehm.sad fsafdf saasf asdf sadf asdfasfa sdf?Okay?Pressochè è quello che devi avere in testa tu.
    • rockroll scrive:
      Re: ennesimo fallimento del mondo open
      - Scritto da: dumah
      le OpenGL hanno fallito =
      ennesimo fallimento
      del mondo
      open.
      Ci fosse un progetto open che venga adottato
      seriamente!Sei proprio convinto di quello che vai dicendo (o che ti fanno dire)?
Chiudi i commenti