專利名稱：圖形指令發(fā)送裝置及圖形指令發(fā)送方法
技術(shù)領(lǐng)域：
本發(fā)明涉及發(fā)送用于在客戶端一側(cè)繪制包括多個圖形要素的畫面的指令集圖形 指令發(fā)送裝置。
背景技術(shù)：
當(dāng)前，除了個人計算機之外，還存在很多移動電話、PDA(PerSOnalDigital Assistance 個人數(shù)字助理)等移動設(shè)備，接收圖形數(shù)據(jù)的客戶終端正不斷地向多樣化發(fā) 展。這些客戶終端一般在CPU的處理能力、有無專用IC等性能方面不相同。另外，由于近 年來多媒體的發(fā)展，可以通過網(wǎng)絡(luò)等用電子設(shè)備等獲取靜止圖像或動態(tài)圖像數(shù)據(jù)的多種圖 形數(shù)據(jù)，伴隨著網(wǎng)絡(luò)通信速度的高速化，圖形數(shù)據(jù)的容量也增大。在這樣的背景下，根據(jù)客戶端的電子設(shè)備的種類等在服務(wù)器一側(cè)進行圖形數(shù)據(jù)的 編輯。例如，在專利文獻1中，揭示了以下服務(wù)器裝置即，在服務(wù)器上再現(xiàn)用戶的顯示環(huán) 境，在服務(wù)器一側(cè)判斷是否能毫無問題地顯示客戶端所希望瀏覽的網(wǎng)頁，在有問題的情況 下，在進行適當(dāng)?shù)淖儞Q后，將網(wǎng)頁數(shù)據(jù)發(fā)送到客戶端。利用該裝置，不管網(wǎng)頁的描述語言、瀏 覽器的性質(zhì)如何，客戶端都能可靠地進行適合自身顯示環(huán)境的、方便瀏覽的顯示。專利文獻1 日本專利特開2006-3147
發(fā)明內(nèi)容
然而，在上述那樣的現(xiàn)有技術(shù)中，若客戶端具有繪制圖形要素的最低限度的能力， 則以包含用于繪制該圖形要素的指令的形式來發(fā)送圖形數(shù)據(jù)。因此，即使是并沒有那么重 要的圖形要素，為了在客戶端一側(cè)對其進行接收或繪制也需要時間，因而不能說是發(fā)送了 最佳的圖形數(shù)據(jù)。為了解決上述問題，本發(fā)明提出一種圖形指令發(fā)送裝置，該圖形指令發(fā)送裝置具 有以下功能即，從客戶端獲取用于繪制圖形要素的指令執(zhí)行能力信息，根據(jù)指令執(zhí)行能力 信息和圖形的重要性等信息選擇構(gòu)成圖形整體的各指令，將基于該選擇生成的指令集發(fā)送 至客戶端。根據(jù)本發(fā)明，鑒于圖形要素的重要性等進行各指令的選擇，因此與現(xiàn)有技術(shù)相比， 減少了不必要地耗費客戶端處理能力的情況。


圖1是實施例1的概要圖。圖2是實施例1所涉及的圖形指令發(fā)送裝置的功能框圖。圖3是表示實施例1所涉及的圖形指令發(fā)送裝置獲取指令執(zhí)行能力信息的一個實 例的圖。圖4是表示在實施例1所涉及的圖形指令發(fā)送裝置中所保持的用于繪制圖形要素的指令的一個實例的圖。圖5是表示向?qū)嵤├?所涉及的圖形指令發(fā)送裝置進行了圖形數(shù)據(jù)發(fā)送請求的客 戶端的指令執(zhí)行能力信息的一個實例的圖。圖6是表示作為客戶端請求實施例1所涉及的圖形指令發(fā)送裝置發(fā)送的對象的圖 形數(shù)據(jù)的一個實例的圖。圖7是表示執(zhí)行了圖6的圖形數(shù)據(jù)的情況下所繪制的圖形的圖。
圖8是表示基于客戶端1的指令執(zhí)行能力信息而構(gòu)成的圖形數(shù)據(jù)的圖。圖9是表示執(zhí)行了圖8的圖形數(shù)據(jù)的情況下所繪制的圖形的圖。圖10是實施例1所涉及的圖形指令發(fā)送裝置的具體構(gòu)成圖。圖11是表示實施例1所涉及的圖形指令發(fā)送裝置的處理流程的流程圖。圖12是實施例2所涉及的圖形指令發(fā)送裝置的功能框圖。圖13是表示實施例2所涉及的圖形指令發(fā)送裝置中所保持的對應(yīng)信息的一個實 例的圖(將“指令的特性”設(shè)為標(biāo)簽的種類的情況)。圖14是表示在實施例2所涉及的圖形指令發(fā)送裝置中所保持的、被賦予了新的屬 性的指令的一個實例的圖。圖15是表示實施例2所涉及的圖形指令發(fā)送裝置中所保持的對應(yīng)信息的一個實 例的圖(將“指令的特性”設(shè)為要素的重要性的情況)。圖16是表示作為客戶端請求實施例2所涉及的圖形指令發(fā)送裝置發(fā)送的對象的 圖形數(shù)據(jù)的一個實例的圖。圖17是表示基于客戶端1的指令執(zhí)行能力信息及對應(yīng)信息而構(gòu)成的圖形數(shù)據(jù)的 圖。圖18是表示基于客戶端2的指令執(zhí)行能力信息及對應(yīng)信息而構(gòu)成的圖形數(shù)據(jù)的 圖。圖19是表示執(zhí)行了圖18的圖形數(shù)據(jù)的情況下所繪制的圖形的圖。圖20是實施例2所涉及的圖形指令發(fā)送裝置的具體構(gòu)成圖。圖21是表示實施例2所涉及的圖形指令發(fā)送裝置的處理流程的流程圖。標(biāo)號說明0200圖形指令發(fā)送裝置0201指令執(zhí)行能力信息獲取部0202指令保持部0203指令選擇部0204指令集構(gòu)成部0205指令集發(fā)送部
具體實施例方式下面，說明本發(fā)明的實施例。實施例與權(quán)利要求的相互關(guān)系如下所述。實施例1 主要涉及權(quán)利要求1、權(quán)利要求3等，實施例2主要涉及權(quán)利要求2、權(quán)利要求4等。此外， 本發(fā)明不限于上述任一實施例，在不脫離本發(fā)明要點的范圍內(nèi)，能夠以各種形態(tài)來實施。實施例1
< 概要 >本實施例的圖形指令發(fā)送裝置具有以下功能從客戶端獲取用于繪制圖形要素的指令執(zhí)行能力信息，根據(jù)該執(zhí)行能力的信息選擇構(gòu)成圖形的各指令，將基于該選擇生成的 指令集發(fā)送至客戶端。用圖1說明本實施例的圖形指令發(fā)送裝置的概要。此處，考慮圖形 指令發(fā)送裝置從處理能力不同的兩個客戶終端接收到用戶接口(UI)數(shù)據(jù)的發(fā)送請求的情 況。兩個終端都可以原樣地執(zhí)行保持在圖形指令發(fā)送裝置中的UI數(shù)據(jù)，但是低處理能力 的機型需要更多的處理時間來執(zhí)行動畫等特定的圖形指令。在這種情況下，本實施例的圖 形指令發(fā)送裝置可以對各指令進行選擇，使得不包含低處理能力的機型需要處理時間的指 令，基于該選擇構(gòu)成圖形指令集并進行發(fā)送。因此，與現(xiàn)有技術(shù)相比較，減少了不必要地耗 費客戶端處理能力的情況?！唇Y(jié)構(gòu)〉圖2是表示本實施例的圖形指令發(fā)送裝置的功能塊的一個實例的圖。作為本發(fā)明的構(gòu)成要素的各部由硬件、或軟件、或硬件和軟件這兩者構(gòu)成。例如， 作為實現(xiàn)上述各部的一個實例，在利用計算機的情況下，可以舉出包括CPU、主存儲器、總 線、接口、周邊設(shè)備等的硬件、和可在這些硬件上實現(xiàn)的軟件。具體而言，通過依次執(zhí)行在主 存儲器上展開的程序，對主存儲器上的數(shù)據(jù)、或經(jīng)由接口輸入的數(shù)據(jù)進行加工、存貯、輸出 等，從而實現(xiàn)各部的功能。圖2中，本實施例的“圖形指令發(fā)送裝置” 0200包括“指令執(zhí)行能力信息獲取 部” 0201、“指令保持部” 0202、“指令選擇部” 0203、“指令集構(gòu)成部” 0204、和“指令集發(fā)送 部”0205。此外，本發(fā)明不僅能夠作為裝置來實現(xiàn)，也可以作為方法來實現(xiàn)。(整篇說明書 中情況相同。)“指令執(zhí)行能力信息獲取部”采用從客戶端獲取指令執(zhí)行能力信息的結(jié)構(gòu)，該指令 執(zhí)行能力信息是對各圖形要素表示用于在客戶端繪制圖形要素的指令的執(zhí)行能力的信息。 此處，“指令執(zhí)行能力信息”可以考慮例如圖3所示那樣的信息。在該圖中，“標(biāo)簽”表示圖 形數(shù)據(jù)中所包含的圖形要素的種類，“屬性”表示可對各圖形要素指定的性質(zhì)。另外，“對應(yīng) 狀況”表示對于各標(biāo)簽或?qū)傩?，客戶端一?cè)是否具有執(zhí)行能力或具有何種等級的執(zhí)行能力。 若進行具體說明，則對于表示文本數(shù)據(jù)的繪制指令的“text”標(biāo)簽的所有屬性，客戶端能夠 以硬件對應(yīng)，但是對于“rect”標(biāo)簽中所包含的“stroke-width”屬性，判斷為以軟件對應(yīng)。 另外，對于“audio”標(biāo)簽的所有屬性，判斷為未對應(yīng)。指令執(zhí)行能力信息的獲取方法可以考慮例如以下的方法。首先，客戶端向圖形指 令發(fā)送裝置發(fā)送自身的指令執(zhí)行能力信息，并進行登記。圖形指令發(fā)送裝置將該指令執(zhí)行 能力信息與客戶端ID相關(guān)聯(lián)地保持在存儲裝置中，并將該ID發(fā)送到客戶端?？蛻舳嗽诎l(fā) 送圖形數(shù)據(jù)的發(fā)送請求時，同時發(fā)送自身的客戶端ID，從而圖形指令發(fā)送裝置可以從存儲 裝置中獲取客戶端的指令執(zhí)行能力。另外，作為其他方法，也可以考慮以下方法S卩，各客戶端將機型名稱及軟件的版 本信息等發(fā)送到圖形指令發(fā)送裝置，圖形指令發(fā)送裝置從與該信息相關(guān)聯(lián)地保持在存儲裝 置中的指令執(zhí)行能力信息中獲取各客戶端的指令執(zhí)行能力?！爸噶畋３植俊辈捎靡韵陆Y(jié)構(gòu)即，將用于使客戶端繪制圖形要素的指令與要被繪 制的圖形要素相關(guān)聯(lián)地保持。例如，在圖4中，<text>標(biāo)簽表示用于繪制文本要素的指令，與用于顯示文本數(shù)據(jù)的圖形要素相關(guān)聯(lián)地保持。在該例中，成為繪制“內(nèi)容指南”的字符。 此處，<切#>標(biāo)簽中所包含的、”、“7”、“打11”、“偽壯-&狀”表示與標(biāo)簽相關(guān)的屬性，因此 分別是指定文本的繪制起點的X坐標(biāo)、文本的繪制起點的Y坐標(biāo)、文本的顏色、文本的大小 的指令?！爸噶钸x擇部”采用以下結(jié)構(gòu)即，為了構(gòu)成用于生成包括多個圖形要素的畫面的 指令集，根據(jù)上述指令執(zhí)行能力信息對各圖形要素選擇指令。例如，可以采用以下結(jié)構(gòu) 艮口，對于指令中所包含的標(biāo)簽及屬性在客戶端一側(cè)未對應(yīng)的情況下，不選擇該標(biāo)簽及屬性。 若對圖3的客戶端的情況進行說明，則由于該客戶端僅未與〈audio〉標(biāo)簽對應(yīng)，因此可以 不選擇指令中包含〈audio〉標(biāo)簽的指令，而選擇其他的指令。另外，也可以采用以下結(jié)構(gòu) 艮口，僅在指令中所包含的標(biāo)簽及屬性與硬件對應(yīng)的情況下，包含該指令。例如，<rect>標(biāo)簽 的 “X、y”、“fill”、“stroke” 與硬件對應(yīng)，因此對其進行選擇，“Strokeiidth”、“rX、ry”、 “fill-opacity”僅與軟件對應(yīng)，因此不對其進行選擇。通過采用這樣的結(jié)構(gòu)，從而可以僅選 擇在客戶端可高速顯示的、與硬件對應(yīng)的圖形要素。 “指令集構(gòu)成部”采用根據(jù)選擇來構(gòu)成指令集的結(jié)構(gòu)?！案鶕?jù)選擇構(gòu)成指令集”的 方法可以作如下考慮例如，在有來自客戶端的圖形數(shù)據(jù)的發(fā)送請求的情況下，基于指令保 持部中存在的該圖形數(shù)據(jù)來構(gòu)成新的圖形數(shù)據(jù)，使得僅留下指令選擇部所選擇的指令。另 夕卜，為了使指令選擇部未選擇的指令無效，也可以添加特定的指令(加注釋的指令等)來構(gòu) 成新的圖形數(shù)據(jù)。“指令集發(fā)送部”采用發(fā)送所構(gòu)成的指令集的結(jié)構(gòu)?！鞍l(fā)送指令集”的方法可以考 慮通過網(wǎng)絡(luò)向客戶端發(fā)送的方法、或通過無線發(fā)送的方法。具體說明在指令執(zhí)行能力不同的客戶端所繪制的圖形的差異。設(shè)各客戶端 具有圖5所示那樣的指令執(zhí)行能力。客戶端1、2對于〈rect〉標(biāo)簽的<rx、ry>屬性及 <fill-opacity>屬性、以及〈animate〉標(biāo)簽的指令執(zhí)行能力不同。<rect>標(biāo)簽的<rx、ry> 屬性是使四邊形的四個角變圓的屬性，〈fill-opacity〉屬性是使背景半透明的屬性。另外， 〈animate〉標(biāo)簽是與動畫功能相關(guān)的標(biāo)簽，使字符可以滾動等。此處，考慮對于圖6所示的 XML數(shù)據(jù)有來自不同客戶端的發(fā)送請求的情況。該XML數(shù)據(jù)中包含有在各客戶端的指令執(zhí) 行能力不同的指令。若原樣執(zhí)行該XML數(shù)據(jù)，則顯示圖7那樣的圖形。如圖5所示，客戶端1以硬件對應(yīng)XML數(shù)據(jù)中所包含的所有指令。因此，在指令選 擇部中，即使在采用僅選擇以硬件對應(yīng)的圖形要素指令的結(jié)構(gòu)的情況下，也選擇上述所有 指令。因此，利用指令構(gòu)成部構(gòu)成的客戶端1用的XML數(shù)據(jù)與指令保持部中原本就存在的 圖6的XML數(shù)據(jù)沒有差異。因此，在客戶端1所顯示的圖形也與圖7相同。接下來，若從指令保持部中存在的構(gòu)成XML數(shù)據(jù)的指令中，基于圖5所示的客戶端 2的指令執(zhí)行能力信息來選擇各指令，則構(gòu)成圖8那樣的XML數(shù)據(jù)?？蛻舳?以軟件對應(yīng) <rect>標(biāo)簽的<rx、ry>及<fill-opacity>屬性，而且〈animate〉標(biāo)簽為未對應(yīng)，因此不選 擇這些指令。因此，若執(zhí)行客戶端2用的該XML數(shù)據(jù)，則繪制圖9所示那樣的圖形。此外，在上述例中，“選擇”是否將構(gòu)成圖形的各圖形要素的指令作為發(fā)送至客戶 端的數(shù)據(jù)而留下來構(gòu)成指令集，但在對于各圖形要素預(yù)先存在多個指令作為選項的情況 下，也可以采用從該選項“選擇”特定的指令來構(gòu)成指令集的結(jié)構(gòu)。<具體結(jié)構(gòu)>
接著，說明本實施例的圖形指令發(fā)送裝置的各硬件構(gòu)成部的動作。圖10是表示本 實施例的圖形指令發(fā)送裝置的硬件構(gòu)成的一個實例的簡圖。如該圖所示，指令執(zhí)行能力信 息獲取部、指令選擇部、及指令集構(gòu)成部包括“CPU” 1001和“主存儲器” 1002。指令保持部 包括“存儲裝置(或存儲介質(zhì))” 1003。指令集發(fā)送部包括“網(wǎng)絡(luò)接口” 1004。這些構(gòu)件通 過系統(tǒng)總線等數(shù)據(jù)通信路徑相互連接，進行信息的收發(fā)和處理。存儲裝置存儲由CPU執(zhí)行的各種程序等。主存儲器提供作為CPU執(zhí)行程序時的操 作區(qū)域的工作區(qū)域。對該主存儲器和存儲裝置分別分配多個地址，CPU執(zhí)行的程序通過確定 并訪問該地址，可相互進行數(shù)據(jù)交換和處理。在以下的說明中，采用將程序預(yù)先在主存儲器 的工作區(qū)域中展開并長期保持的結(jié)構(gòu)，但必要情況下也可以采用從存儲裝置調(diào)出的結(jié)構(gòu)。在網(wǎng)絡(luò)接口中，從客戶端接收到圖形指令集的發(fā)送請求及客戶端ID的情況下，指 令執(zhí)行能力信息獲取程序?qū)⒈３衷诖鎯ρb置中的指令執(zhí)行能力信息表存放到主存儲器的 預(yù)定地址中，檢索與上述客戶端ID相關(guān)聯(lián)的信息，并提取到主存儲器的預(yù)定地址中。此外， 此處采用預(yù)先將客戶端的指令執(zhí)行能力信息與各客戶端ID相關(guān)聯(lián)地保持在存儲裝置中的 結(jié)構(gòu)，但也可以采用在接收到圖形指令集的發(fā)送請求的同時從客戶端直接獲取指令執(zhí)行能 力信息的結(jié)構(gòu)等。指令選擇程序在進行了發(fā)送請求的客戶端的指令執(zhí)行能力信息存放到主存儲器 中的情況下，從存儲裝置中獲取作為發(fā)送請求對象的圖形指令集，將其存放到主存儲器的 預(yù)定地址中。此外，也可以采用通過網(wǎng)絡(luò)接口從外部獲取圖形指令集的結(jié)構(gòu)。此后，指令選 擇程序基于指令執(zhí)行能力信息進行用于判斷是否選擇表示圖形要素的各指令的處理。在進 行指令的選擇判斷處理時，可以采用在沒有最低限度的指令執(zhí)行能力的情況下不選擇該指 令的結(jié)構(gòu)，也可以采用在指令執(zhí)行能力未達到一定基準(zhǔn)的情況下不選擇該指令的結(jié)構(gòu)。一 定基準(zhǔn)可以在圖形指令發(fā)送裝置中設(shè)定。指令集構(gòu)成程序基于上述指令選擇程序的處理結(jié)果，利用CPU進行用于構(gòu)成圖形 指令集的處理。所構(gòu)成的圖形指令集通過網(wǎng)絡(luò)接口發(fā)送至進行了發(fā)送請求的客戶端。<處理流程>圖11是表示本實施例的圖形指令發(fā)送裝置的處理流程的一個實例的圖。此處，設(shè) 已經(jīng)完成了為了將用于使客戶端繪制圖形要素的指令與要被繪制的圖形要素相關(guān)聯(lián)地保 持而記錄的步驟。該圖的處理流程包括以下步驟。首先，在步驟SllOl中，判斷是否接收到 來自客戶端的圖形數(shù)據(jù)的發(fā)送請求。在這里的判斷為接收到的情況下，前進至步驟S1102。 在這里的判斷為未接收到的情況下，待機。在步驟S1102中，從指令保持部獲取客戶端所請 求發(fā)送的指令集。在步驟S1103中，判斷是否可以獲取進行了發(fā)送請求的客戶端的指令執(zhí) 行能力信息。在這里的判斷為可以獲取的情況下，前進至步驟S1104A。在這里的判斷為無 法獲取的情況下，前進至步驟S1104B。該處理主要由指令執(zhí)行能力信息獲取部執(zhí)行。在步 驟S1104B中，將從指令保持部獲取的指令集原樣發(fā)送至客戶端，結(jié)束處理。在步驟S1104A 中，根據(jù)指令執(zhí)行能力信息判斷是否選擇構(gòu)成圖形畫面的各圖形要素的指令。該處理主要 由指令選擇部執(zhí)行。在步驟S1105A中，根據(jù)指令選擇部的選擇構(gòu)成用于繪制圖形畫面的指 令集。該處理主要由指令集構(gòu)成部執(zhí)行。在步驟S1106A中，對進行了發(fā)送請求的客戶端發(fā) 送在指令集構(gòu)成部構(gòu)成的指令集。該處理主要由指令集發(fā)送部執(zhí)行。上述處理可以由用于使計算機執(zhí)行的程序來執(zhí)行，還可以將該程序記錄在計算機可讀取的記錄介質(zhì)中(整篇說明書中情況相同)。< 效果 > 在本發(fā)明的圖形指令發(fā)送裝置中，當(dāng)圖形數(shù)據(jù)中包含與在客戶端一側(cè)進行繪制的 執(zhí)行能力較低的圖形要素相關(guān)的指令時，即使具有指令執(zhí)行能力信息，也可以以不包含該 指令的形態(tài)構(gòu)成圖形數(shù)據(jù)，將其發(fā)送至客戶端，因此減少了不必要地消耗客戶端處理能力 的情況。實施例2< 概要 >本實施例的圖形發(fā)送裝置基本上與實施例1的裝置相同，不同點在于具有以下特 征即，不僅僅基于任意客戶端的指令執(zhí)行能力信息，還基于各指令的特性來決定是否選擇 該指令。< 結(jié)構(gòu) >圖12是表示本實施例的圖形指令發(fā)送裝置的功能塊的一個實例的圖。在圖12中，本實施例的“圖形指令發(fā)送裝置” 1200包括“指令執(zhí)行能力信息獲 取部” 1201、“指令保持部” 1202、“指令選擇部” 1203、“指令集構(gòu)成部” 1204、“指令集發(fā)送 部” 1205、及“對應(yīng)信息保持部” 1206。由于結(jié)構(gòu)基本上與實施例1中記載的裝置的結(jié)構(gòu)相 同，因此，下面對它們的不同之處即對應(yīng)信息保持部進行詳細的描述?！皩?yīng)信息保持部”采用保持對應(yīng)信息的結(jié)構(gòu)，上述對應(yīng)信息對應(yīng)于任意客戶端的 各指令的執(zhí)行能力及各指令的特性決定是否利用指令選擇部選擇該指令?！爸噶畹奶匦浴北硎緦χ噶罴由咸卣鞯男再|(zhì)?？梢钥紤]例如將標(biāo)簽的種類設(shè)為“指 令的特性”。在這種情況下，可以考慮預(yù)先保持圖13中示出的數(shù)據(jù)作為對應(yīng)信息。在該例 中，對于包含<text>標(biāo)簽的指令，在客戶端為未對應(yīng)的情況下，在指令選擇部不選擇該指 令，若以硬件或軟件對應(yīng)，則選擇該指令。另外，對于包含〈animate〉標(biāo)簽的指令，在客戶端 為未對應(yīng)或以軟件對應(yīng)的情況下，不選擇該指令，僅在以硬件對應(yīng)的情況下選擇該指令。此 處，在關(guān)于同一標(biāo)簽包含指令執(zhí)行能力不同的屬性的情況下，考慮根據(jù)指令執(zhí)行能力較低 的屬性來判斷指令執(zhí)行能力的結(jié)構(gòu)。例如，在圖5所示的客戶端2中，關(guān)于〈rect〉標(biāo)簽， <fill>屬性和<fill-opacity〉屬性具有不同的指令執(zhí)行能力。在這種情況下，關(guān)于<rect> 標(biāo)簽，根據(jù)指令執(zhí)行能力較低的<fill-opacity〉屬性，判斷為“以軟件對應(yīng)”。另外，也可以 同樣地將標(biāo)簽中所包含的各屬性設(shè)為“指令的特性”，對各標(biāo)簽的屬性保持對應(yīng)信息。而且，還可以將對指令新添加的屬性設(shè)為“指令的特性”。在圖14所示的例中，對 特定的指令添加了〈rating〉(要素的重要性)作為新的屬性，將該屬性設(shè)為“指令的特性”。 在這種情況下，可以考慮預(yù)先保持圖15中示出的數(shù)據(jù)作為對應(yīng)信息。此處，對于將重要性 設(shè)定為“重要(high) ”的指令，在客戶端為未對應(yīng)的情況下，在上述選擇部中不選擇該指令， 但是若以硬件或軟件對應(yīng)，則選擇該指令。另外，對于將重要性設(shè)定為“通常(normal)”的 指令，在客戶端為未對應(yīng)或以軟件對應(yīng)的情況下不選擇該指令，僅在以硬件對應(yīng)的情況下 選擇該指令。此處，將重要性的基準(zhǔn)分為“重要(high)”和“通常(normal)”這兩級，但也 可以設(shè)定為比兩級要大的數(shù)。另外，作為新的屬性，并不限于上述的〈rating〉(要素的重要性)，也可以考慮設(shè) 為〈datasizeX圖形要素的數(shù)據(jù)大小)。在將“指令的特性”設(shè)為〈datasize〉的情況下，可以根據(jù)各圖形要素的數(shù)據(jù)大小是否超過一定的基準(zhǔn)大小，判斷是否選擇用于繪制該要素的 指令。此外，還可以將新的屬性設(shè)為簡單的識別標(biāo)號等。例如，作為識別標(biāo)號可以考慮對 特定的指令添加“0、1”的情況。在這種情況下，可以采用以下結(jié)構(gòu)即，對于將識別標(biāo)號設(shè) 定為“0”的指令，若客戶端以硬件或軟件對應(yīng)則選擇該指令，對于將識別標(biāo)號設(shè)定為“1”的 指令，僅在客戶端以硬件對應(yīng)的情況下選擇該指令。
以下，具體說明將“指令的特性”設(shè)定為〈rating〉(要素的重要性)的情況下，對 指令執(zhí)行能力不同的各客戶端構(gòu)成的指令集的差異。設(shè)各客戶端具有實施例1的圖5所示 的指令執(zhí)行能力。此處，客戶端1、2在<rect>標(biāo)簽的<rx、ry>及〈fill-opacity〉屬性、以 及〈animate〉標(biāo)簽上的指令執(zhí)行能力不同。在各客戶端向包含這些指令的圖形數(shù)據(jù)進行了 發(fā)送請求的情況下，指令選擇部基于該指令執(zhí)行能力和圖15所示的對應(yīng)信息選擇指令，因 此對各客戶端構(gòu)成不同的指令集。例如，如圖16那樣，考慮指令保持部中保持有向在各客戶端的指令執(zhí)行能力不同 的指令添加了〈rating〉屬性的XML數(shù)據(jù)的情況。在原樣執(zhí)行了該XML數(shù)據(jù)的情況下，繪 制圖7所示那樣圖形。若從以該XML數(shù)據(jù)表示的指令集中，基于圖5所示的客戶端1的指 令執(zhí)行能力信息和圖15所示的對應(yīng)信息來選擇指令，則構(gòu)成圖17所示的XML數(shù)據(jù)。對于 〈rating〉屬性，在客戶端一側(cè)繪制圖形時是不需要的，因此可以采用刪除〈rating〉屬性的 結(jié)構(gòu)，但是也可以采用原樣留下該〈rating〉屬性的描述的結(jié)構(gòu)?？蛻舳?對所有的指令 都以硬件對應(yīng)，因此實際上與指令保持部中存在的圖16的XML數(shù)據(jù)沒有差異。因此，若執(zhí) 行客戶端1用的XML數(shù)據(jù)，則繪制圖7所示的圖形。與此相反，若基于圖5所示的客戶端2 的指令執(zhí)行能力信息及圖15所示的對應(yīng)信息來選擇指令，則構(gòu)成圖18那樣的XML數(shù)據(jù)。 客戶端2對于<rect>標(biāo)簽的<rx、ry>及〈fill-opacity〉屬性以軟件對應(yīng)，但是選擇重要 度為“重要”的<rect>標(biāo)簽的<rx、ry>屬性，而不選擇重要度為“通常”的<rect>標(biāo)簽的 〈fill-opacity〉屬性。另外，由于〈animate〉標(biāo)簽為未對應(yīng)，因此未被選擇。因此，若執(zhí)行 客戶端2用的XML數(shù)據(jù)，則繪制圖19所示的圖形，與客戶端1的圖形不同。此外，在上述例中，“選擇”是否將構(gòu)成圖形的各圖形要素的指令作為發(fā)送至客戶 端的數(shù)據(jù)而留下，來構(gòu)成指令集，但是在對各圖形要素存在多個指令作為預(yù)選項的情況下， 也可以從該選項中“選擇”特定的指令來構(gòu)成指令集?！淳唧w結(jié)構(gòu)〉圖20是表示本實施例的圖形指令發(fā)送裝置的硬件構(gòu)成的一個實例的簡圖。該結(jié) 構(gòu)基本上與用圖10說明的實施例1的裝置的硬件構(gòu)成相同。但本實施例的裝置在“存儲裝 置(或者存儲介質(zhì))”中保持有對應(yīng)信息。在網(wǎng)絡(luò)接口中接收到圖形指令集的發(fā)送請求及客戶端ID的情況下，指令執(zhí)行能 力信息獲取程序?qū)⒈３衷诖鎯ρb置中的指令執(zhí)行能力信息存放到主存儲器的預(yù)定地址中， 檢索與上述客戶端ID相關(guān)聯(lián)的信息，提取到主存儲器的預(yù)定地址中。此處，采用預(yù)先將客 戶端的指令執(zhí)行能力信息與各客戶端ID相關(guān)聯(lián)地保持在存儲裝置中的結(jié)構(gòu)，但也可以采 用在接收到圖形指令集的發(fā)送請求的同時從客戶端直接獲取指令執(zhí)行能力信息的結(jié)構(gòu)。指令選擇程序在將進行了發(fā)送請求的客戶端的指令執(zhí)行能力信息存放到主存儲 器中的情況下，從存儲裝置中獲取對應(yīng)信息及作為發(fā)送請求對象的圖形指令集(指令信息)，將其存放到主存儲器的預(yù)定地址中。此外，也可以采用通過網(wǎng)絡(luò)接口從外部獲取圖形指令集的結(jié)構(gòu)。此后，指令選擇程序基于指令執(zhí)行能力及對應(yīng)信息，進行用于判斷是否選擇 表示圖形要素的各指令的處理。指令集構(gòu)成程序基于上述指令選擇程序的處理結(jié)果，利用CPU進行用于構(gòu)成圖形 指令集的處理。所構(gòu)成的圖形指令集通過網(wǎng)絡(luò)接口發(fā)送至進行了發(fā)送請求的客戶端。<處理流程>圖21是表示本實施例的圖形指令發(fā)送裝置的處理流程的一個實例的圖。此處，設(shè) 定為已經(jīng)完成了為了將用于使客戶端繪制圖形要素的指令與要被繪制的圖形要素相關(guān)聯(lián) 地保持而記錄的步驟。另外，還設(shè)定為也已經(jīng)完成了為了保持對應(yīng)于任意客戶端的各指令 的執(zhí)行能力及各指令的特性決定是否選擇該指令的對應(yīng)信息而記錄的步驟。該圖的處理 流程包括以下步驟。首先，在步驟S2101中，判斷是否接收到來自客戶端的圖形數(shù)據(jù)的發(fā) 送請求。在這里的判斷為接收到的情況下，前進至步驟S2102。在這里的判斷為未接收到 的情況下，待機。在步驟S2102中，從指令保持部獲取客戶端所請求發(fā)送的指令集。在步驟 S2103中，判斷是否可以獲取進行了發(fā)送請求的客戶端的指令執(zhí)行能力信息。在這里的判斷 為可以獲取的情況下，前進至步驟S2104A。在這里的判斷為無法獲取的情況下，前進至步 驟S2104B。該處理主要由指令執(zhí)行能力信息獲取部執(zhí)行。在步驟S2104B中，將從指令保 持部獲取的指令集原樣發(fā)送至客戶端，結(jié)束處理。在步驟S2104A中，判斷是否可以從對應(yīng) 信息保持部獲取與客戶端請求發(fā)送的圖形數(shù)據(jù)相對應(yīng)的對應(yīng)信息。在這里的判斷為可以獲 取的情況下，前進至步驟S2105A。在這里的判斷為無法獲取的情況下，前進至步驟S2105C。 從步驟S2105C開始，與實施例1的 < 處理流程 > 的步驟S1104A開始的處理相同。在步驟 S2105A中，根據(jù)指令執(zhí)行能力信息及對應(yīng)信息判斷是否選擇構(gòu)成圖形畫面的各圖形要素的 指令。該處理主要由指令選擇部執(zhí)行。在步驟S2106A中，根據(jù)指令選擇部的選擇構(gòu)成用于 繪制圖形畫面的指令集。該處理主要由指令集構(gòu)成部執(zhí)行。在步驟S2107A中，對進行了發(fā) 送請求的客戶端發(fā)送在指令集構(gòu)成部構(gòu)成的指令集。該處理主要由指令集發(fā)送部執(zhí)行。< 效果 >在本發(fā)明的圖形指令發(fā)送裝置中，在圖形數(shù)據(jù)中包含有與在客戶端一側(cè)進行繪制 的執(zhí)行能力較低、且進行繪制的必要性較小的圖形要素相關(guān)的指令的情況下，可以以不包 含該指令的形態(tài)構(gòu)成圖形數(shù)據(jù)，將其發(fā)送至客戶端，因此減少了不必要地消耗客戶端處理 能力的情況。
權(quán)利要求
一種圖形指令發(fā)送裝置，其特征在于，包括指令執(zhí)行能力信息獲取部，該指令執(zhí)行能力信息獲取部從客戶端獲取指令執(zhí)行能力信息，該指令執(zhí)行能力信息是對各圖形要素表示用于在客戶端繪制圖形要素的指令的執(zhí)行能力的信息；指令保持部，該指令保持部將用于使客戶端繪制圖形要素的指令與要被繪制的圖形要素相關(guān)聯(lián)地進行保持；指令選擇部，該指令選擇部為了構(gòu)成用于生成包括多個圖形要素的畫面的指令集，根據(jù)所述指令執(zhí)行能力信息對各圖形要素選擇指令；指令集構(gòu)成部，該指令集構(gòu)成部根據(jù)選擇來構(gòu)成指令集；以及，指令集發(fā)送部，該指令集發(fā)送部發(fā)送所構(gòu)成的指令集。
2.如權(quán)利要求1所述的圖形指令發(fā)送裝置，其特征在于，還包括對應(yīng)信息保持部，該對應(yīng)信息保持部保持對應(yīng)信息，該對應(yīng)信息對應(yīng)于任意客 戶端的各指令的執(zhí)行能力及各指令的特性來決定是否利用指令選擇部選擇該指令。
3.一種圖形指令發(fā)送方法，其特征在于，包括從客戶端獲取指令執(zhí)行能力信息的步驟，所述指令執(zhí)行能力信息是對各圖形要素表示 用于在客戶端繪制圖形要素的指令的執(zhí)行能力的信息；為了將用于使客戶端繪制圖形要素的指令與要被繪制的圖形要素相關(guān)聯(lián)地保持而進 行記錄的步驟；為了構(gòu)成用于生成包括多個圖形要素的畫面的指令集，根據(jù)所述指令執(zhí)行能力信息對 各圖形要素選擇指令的步驟；根據(jù)選擇來構(gòu)成指令集的步驟；以及，發(fā)送所構(gòu)成的指令集的步驟。
4.如權(quán)利要求3所述的圖形指令發(fā)送方法，其特征在于，還包括為了保持對應(yīng)信息而記錄的步驟，所述對應(yīng)信息對應(yīng)于任意客戶端的各指令的 執(zhí)行能力及各指令的特性決定是否利用指令選擇部來選擇該指令。
全文摘要
在現(xiàn)有技術(shù)中，即使是對于構(gòu)成圖形的數(shù)據(jù)而言并不重要的圖形要素，為了在客戶端一側(cè)對其進行接收或繪制也需要時間，因而不能說是向客戶端發(fā)送了最佳的圖形數(shù)據(jù)。為了解決上述問題，本發(fā)明提出了一種圖形指令發(fā)送裝置，該圖形指令發(fā)送裝置具有以下功能即，根據(jù)客戶端的指令執(zhí)行能力信息和圖形的重要性等信息，選擇構(gòu)成圖形整體的各指令，將基于該選擇而生成的指令集發(fā)送至客戶端。
文檔編號G06F13/00GK101889271SQ200880119648
公開日2010年11月17日 申請日期2008年4月18日 優(yōu)先權(quán)日2007年12月7日
發(fā)明者上道明生, 中村宏之, 佐佐木潤, 坂本憲治, 松山曉, 渡邊龍輔 申請人:夏普株式會社